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. +
