Re: Fixed length data types issue - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Fixed length data types issue
Date
Msg-id 200609102340.k8ANe7t20884@momjian.us
Whole thread Raw
In response to Re: Fixed length data types issue  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Fixed length data types issue  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> Bruce Momjian <bruce@momjian.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@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: Tom Lane
Date:
Subject: Re: contrib uninstall scripts need some love
Next
From: Michael Fuhr
Date:
Subject: contrib/xml2 and PG_MODULE_MAGIC