Re: [HACKERS] compression in LO and other fields

wieck(at)debis(dot)com (Jan Wieck) writes:
> The idea was to use another bit in the tuple header to tell
> if an existing heap tuple's data is compressed or not. So the
> heap fetching allways looks at the bit in the tuple header,
> and the heap appending looks at the flag in the relation
> pointer. That's exactly what you want, no?

Right. Compressed tuples must be unambiguously marked as such on-disk.
Whether to compress a tuple when writing it out is a decision that
can be made on-the-fly, using strategies that could change from time
to time, without invalidating the data that's already out there or
affecting the tuple-reading code.

If we choose to provide also a way of compressing individual fields
rather than whole tuples, it would be good to provide the same
flexibility at the field level. Some tuples might contain the field
in compressed form, some in uncompressed form. The reading logic
should not need to be aware of the way that the writing logic chooses
which to do.

regards, tom lane