Re: [HACKERS] compression in LO and other fields

wieck@debis.com (Jan Wieck) writes:
>     The major problem I see is that a palloc()'d tuple should  be
>     pfree()'d  after  the fetcher is done with it. Since they are
>     in buffer actually, the fetcher doesn't have to care.

I think this may not be as big a problem as it looks.  Most places
in the executor keep tuples in TupleTableSlots, which are responsible
for pfree'ing the tuple if (and only if) necessary; all that code is
ready for this change already.  There are probably some routines in
heapam/indexam that assume they only work with tuples that never need
to be freed, but I don't think the fixes will be pervasive.  And we're
going to have to do that work in any case to support big tuples
(assuming we do it by splitting tuples into segments that fit in disk
pages).

>     And a general
>     mechanism working on the tuple level would fallback to  store
>     uncompressed  data in the case the compressed size is bigger.

Right.  Another possible place for speed-vs-space tuning would be to
store the uncompressed representation unless the compressed version is
at least X percent smaller, not just at-least-one-byte smaller.
        regards, tom lane