Our good friend Virtuous Media has been pushing the group to discuss databases, in a way that's probably not familiar to most of us. When I talk about databases, lately, it's usually about SQL DMVs. Tripy has more experience with more systems, so he's been able to shine the light on a number of things, hidden gotchas when you move to Postgres.

I think this question only applies to SQL Server and Oracle, but again, I don't do MySQL, so I wouldn't know. But I'm curious to find out.

More, I'm curious how many people out there have worked with compression in databases? It's a different kind of thing from mp3 compression, because we're working on smaller blocks. It's not megs and megs we want to shrink to fit in an email. It's records and columns, and nodes in an index, that might be 300 bytes on average. We don't want to shrink them for transfer, it's mostly to help performance on IO bound tasks. There's also backups and the like, but most people who do it say "I can trade off a little CPU to hit the disc less".

How many people out there have tried compressing part or all of their database? How many would like to?

Link drop - http://blogs.msdn.com/sqlserverstora...fault.aspx?p=2 I've been reading this guy, who turned up in a search for a very specific issue, impressed me, and had more interesting stuff. Anyway, this page I'm linking to has a lot of info on how compression is implemented in SQL Server 2008.

It's an interesting concept. Pulling a relevant quote from that page:

The goal of compression in database is NOT to get the maximum compression possible but to find a right balance between the compression achieved and the cost of compressing/de-compressing the data. It will serve you no good if SQL Server can compress the data 90% but the CPU cost of SELECT and DML operations become unacceptably high. You often hear that so and so database system compresses the data 60% while the other database system compresses the same data 40%. The important question to ask is what is the impact on the workload (i.e. CPU)? If the impact on the workload is unacceptable, the customers will not use the data compression in spite of better compression. Ideally, we need to strike a right balance between the compression achieved and its CPU impact.

It seems to me that you would have to working with an awfully large amount of data for it to be useful. It's a very interesting blog, though. I bookmarked it.