| 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: | Whole Thread | Raw Message | 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
| 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? |