More stats on advanced compression

We're doing some more analysis of how much space we can save on our filesystems by implementing advanced compression. We initially looked at this in but some bugs (that we couldn't easily patch for) prevented us from going any further. Now we've upgraded to (we couldn't go any higher as the 3rd party vendor wouldn't certify it) we decided to revisit it.

We did some comparisons by importing the same export file of a copy from live into 2 different schemas/tablespaces - we then compare the resulting size of the objects.

Here is what we found:

Normal 310GB 115GB
Compress for all operations 115GB 99GB

(* advanced compression does not apply to indexes - these were just compressed using old style 'compress')

So we can see there is a huge reduction in the storage required for the tables - the objects end up almost 1/3 of their original size. Indexes is not so amazing but is still OK.

This database has a huge number of tables and a huge mix of types of data so i think probably would accurately reflect the kind of figures you would see from a normal OLTP system.

Now we need to check there are no bugs and also how this impacts performance. In theory it should make a lot of things faster but we had bad experiences with advanced compression in a warehouse system where the overheard of the compression during data loads made very noticeable changes (in the wrong direction) to the batch performance.


Post a Comment