Gregory Stark wrote:
> Tom Lane <[EMAIL PROTECTED]> writes:
> > Gregory Stark <[EMAIL PROTECTED]> writes:
> > > I don't really see a way around it though. Places that fill in VARDATA 
> > > before
> > > the size (formatting.c seems to be the worst case) will just have to be
> > > changed and it'll be a fairly fragile point.
> > 
> > No, we're not going there: it'd break too much code now and it'd be a
> > continuing source of bugs for the foreseeable future.  The sane way to
> > design this is that
> > 
> > (1) code written to existing practice will always generate 4-byte
> > headers.  (Hence, VARDATA() acts the same as now.)  That's the format
> > that generally gets passed around in memory.
> So then we don't need to replace VARSIZE with SET_VARLENA_LEN at all.
> > (2) creation of a short header is handled by the TOAST code just before
> > the tuple goes to disk.
> > 
> > (3) replacement of a short header with a 4-byte header is considered
> > part of de-TOASTing.
> 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.

One weird idea I had was that the macros can read 1 and 4-byte headers,
but can only create 4-byte headers.  The code that writes to the shared
buffer pages would to compression from 1 to 4 bytes as needed.

This might avoid changing any macros.  It also allows us to carry around
4-byte headers in memory, which I think might be more efficient.  I am
not sure if I have heard this idea proposed already or not.

  Bruce Momjian  <[EMAIL PROTECTED]>

  + If your life is a hard drive, Christ can be your backup. +

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at


Reply via email to