This past weekend I was a presenter in two sessions at the SQL Saturday in Tampa. First, I just want to say what an event. The lunch that was served set a new precedence for all of the upcoming SQL Lunches. We had a sit down meal with silverware and plates. Well over and beyond the sandwich, chips and cookie you will get when attending SQL Saturday in Baton Rouge, but I digress. Thanks to everyone that helped to put on such a successful event.
My first session was IRON Chef America SQL. I acted as the chairman or MC of the presentation. I provided the color commentary and kept the show going. In most cases I acted as an instigator between the two competitors, Brian Knight and Adam Jorgensen. The session was great and so far I have only received great comments. I can’t wait to do it again.
My second session was SQL Server Compression 101, which was an introductory session to Backup and Data compression. I had a couple of technical difficulties, but overall I think the presentation was well received. One of the attendees asked about compressed data and its state on disk and in-memory, which was a great question. Simply put, she wanted to know if the data was compressed or decompressed in-memory. Ironically, part of my research addressed this specific question. Data in-memory is compressed. Since decompressing data consumes CPU, data is only decompressed when it is updated or queried as a result (joining, filtering, etc…). Even further, only the data requested is decompressed not the entire page. You can read about this and more about data compression in a great White Paper titled, Data Compression: Strategy, Capacity Planning and Best Practices. The paper was written by Sanjay Mishra of the SQLCat team.
Talk to you soon
Visit www.BIDN.com, Bringing Business Intelligence to your company