| From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
|---|---|
| To: | Gregory Stark <stark(at)enterprisedb(dot)com> |
| Cc: | Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, Phil Currier <pcurrier(at)gmail(dot)com>, "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Column storage positions |
| Date: | 2007-02-21 23:31:35 |
| Message-ID: | 45DCD657.6040802@dunslane.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Gregory Stark wrote:
> "Andrew Dunstan" <andrew(at)dunslane(dot)net> writes:
>
>
>> I would want to see this very carefully instrumented. Assuming we are putting
>> all fixed size objects at the front, which seems like the best arrangement,
>> then the position of every fixed field and the fixed portion of the position of
>> every varlena field can be precalculated (and in the case of the leftmost
>> varlena field that's it's complete position).
>>
>
> I'm not sure what you mean by "the fixed portion of the position of every
> varlena field". Fields are just stuck one after the other (plus alignment)
> skipping nulls. So any field after a null or varlena field can't have its
> position cached at all.
>
I'd forgotten about nulls :-( . Nevertheless, it's hard to think of a
case where the penalty for shifting fixed size fields to the front is
going to be very big. If we really wanted to optimise for speed for some
varlena case, we'd probably need to keep stats on usage patterns, but
that seems like massive overkill.
cheers
andrew
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Gregory Stark | 2007-02-21 23:52:32 | Re: Column storage positions |
| Previous Message | Joshua D. Drake | 2007-02-21 22:59:52 | Re: autovacuum next steps, take 2 |