Re: Variable length varlena headers redux - Mailing list pgsql-hackers

From Greg Stark
Subject Re: Variable length varlena headers redux
Date
Msg-id 87abzighid.fsf@stark.xeocode.com
Whole thread Raw
In response to Re: Variable length varlena headers redux  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Variable length varlena headers redux  (Bruce Momjian <bruce@momjian.us>)
Re: Variable length varlena headers redux  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> writes:

> > So (nigh) every tuple will get deformed and reformed once before it goes to
> > disk? Currently the toast code doesn't even look at a tuple if it's small
> > enough, but in this case we would want it to fire even on very narrow rows.
> 
> I'd be inclined to put the intelligence into heap_form_tuple and thereby
> avoid getting the TOAST code involved unless there are wide fields to
> deal with.

And have heap_deform_tuple / heap_getattr palloc and memcpy the the datum on
the way out? Or wait until detoast time and then do it?

If we do it on the way out of the heaptuple then we could have a rule that
headers are always compressed in a tuple and always uncompressed out of a
tuple.

But I'm surprised, I had the impression that you were reluctant to consider
memcpying all the data all the time.

-- 
greg



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Variable length varlena headers redux
Next
From: Bruce Momjian
Date:
Subject: Re: Variable length varlena headers redux