Re: vacuum, performance, and MVCC, and compression

[Bruce Momjian <bruce(at)momjian(dot)us>]

PFC wrote:
> 
> 	There were some talks lately about compression.
> 	With a bit of lateral thinking I guess this can be used to contain the  
> bloat induced by updates.
> 	Of course this is just my hypothesis.
> 
> 	Compression in indexes :
> 
> 	Instead of storing (value, tuple identifier) keys in the indexes, store  
> (value, [tuple identifier list]) ; ie. all tuples which have the same  
> indexed value are referenced by the same index tuple, instead of having  
> one index tuple per actual tuple.
> 	The length of the list would of course be limited to the space actually  
> available on an index page ; if many rows have the same indexed value,  
> several index tuples would be generated so that index tuples fit on index  
> pages.
> 	This would make the index smaller (more likely to fit in RAM) at the cost  
> of a little CPU overhead for index modifications, but would make the index  
> scans actually use less CPU (no need to compare the indexed value on each  
> table tuple).

What about increasing the size of an existing index entry?  Can that be
done easily when a new row is added?

> 	Compression in data pages :
> 
> 	The article that circulated on the list suggested several types of  
> compression, offset, dictionary, etc. The point is that several row  
> versions on the same page can be compressed well because these versions  
> probably have similar column values.
> 
> 	Just a thought...

I would be worried about the overhead of doing that on compression and
decompression.

-- 
  Bruce Momjian   bruce(at)momjian(dot)us
  EnterpriseDB    http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +