From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Gregory Stark <gsstark(at)mit(dot)edu>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org, Martijn van Oosterhout <kleptog(at)svana(dot)org> |
Subject: | Re: Fixed length data types issue |
Date: | 2006-09-10 23:40:07 |
Message-ID: | 200609102340.k8ANe7t20884@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > * Consider ways of storing rows more compactly on disk
> > o Support a smaller header for short variable-length fields?
>
> With respect to the business of having different on-disk and in-memory
> representations, we have that already today: see TOAST. It strikes me
> that it might be useful to think about solving the problem with a
> "second generation toast mechanism". The first generation only worried
> about storing large values, but the second generation would also address
> the problem of storing small values efficiently.
>
> Or you could think about it as a "second generation varlena". This
> mindset would make for a slightly different set of choices about where
> the work gets done. I'm not sure which is better.
>
> Either way, I think it would be interesting to consider
>
> (a) length word either one or two bytes, not four. You can't need more
> than 2 bytes for a datum that fits in a disk page ...
That is an interesting observation, though could compressed inline
values exceed two bytes?
> (b) alignment either one or two bytes, not four. TEXT would be
> perfectly happy with 1-byte alignment, but for NUMERIC we might want 2.
>
> I'm inclined to bag the idea of storing the length words separately from
> the data proper. Although it probably would make for some marginal gain
> in cache efficiency, I don't see any reasonable way at all to fit it
> into the current system structure, whereas either the "toast" or "next
> gen varlena" approaches seem fairly straightforward. And having to
> track an additional pointer inside the inner loops of heap_form_tuple
> and heap_deform_tuple could eat up any performance gain anyway.
Good point. How do we do it now? I assume we store just the fixed-size
toast pointer length in the heap attribute, not the toast length.
Why haven't we investigated shrinking the varlena header before?
--
Bruce Momjian bruce(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Fuhr | 2006-09-10 23:43:29 | contrib/xml2 and PG_MODULE_MAGIC |
Previous Message | Tom Lane | 2006-09-10 23:38:24 | Re: contrib uninstall scripts need some love |