Re: Packed short varlenas, what next?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Gregory Stark <gsstark(at)mit(dot)edu>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Packed short varlenas, what next?
Date: 2007-02-27 15:52:05
Message-ID: 20432.1172591525@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Gregory Stark <gsstark(at)mit(dot)edu> writes:
> 2) The choice of encoding for toast pointers. Note that currently they don't
> actually save *any* space due to the alignment requirements of the OIDs.
> which seems kind of silly but I didn't see any reasonable way around that.

I was expecting that we'd store them as unaligned and memcpy a toast
pointer into a suitably-aligned local variable any time we wanted to
look at its contents. Detoasting is expensive enough that that's not
going to add any noticeable percentage time-overhead, and not having to
align toast pointers should be a pretty good percentage space-saving,
seeing that they're only 20-some bytes anyway.

> One of the details here is that I didn't store the compressed bit anywhere
> for external toast pointers. I just made the macro compare the rawsize and
> extsize. If that strikes anyone as evil we could take a byte out of those 3
> padding bytes for flags and store a compressed flag there.

I believe this is OK since the toast code doesn't compress unless space
is actually saved. You should put a note in the code that that behavior
is now necessary for correctness, not just a performance tweak.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim C. Nasby 2007-02-27 16:18:31 Re: autovacuum next steps, take 2
Previous Message Gregory Stark 2007-02-27 15:16:46 Re: Packed short varlenas, what next?