Re: vacuum, performance, and MVCC, and compression

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@momjian.us EnterpriseDB    http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +