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

From Bruce Momjian
Subject Re: Variable length varlena headers redux
Date
Msg-id 200702131619.l1DGJIA00442@momjian.us
Whole thread Raw
In response to Re: Variable length varlena headers redux  (Greg Stark <gsstark@mit.edu>)
Responses Re: Variable length varlena headers redux  (Gregory Stark <stark@enterprisedb.com>)
List pgsql-hackers
Greg Stark wrote:
> 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.

Uh, if the macros can read 1 and 4-byte headers, why do we need to
allocate memory for them?

--  Bruce Momjian  <bruce@momjian.us>          http://momjian.us EnterpriseDB
http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: Variable length varlena headers redux
Next
From: Marc Munro
Date:
Subject: Re: Reducing likelihood of deadlocks (was referential Integrity and SHARE locks)