Re: [HACKERS] compression in LO and other fields

wieck@debis.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