Re: Column storage positions - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: Column storage positions
Date
Msg-id 87zm77nnlh.fsf@stark.xeocode.com
Whole thread Raw
In response to Re: Column storage positions  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: Column storage positions  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
"Andrew Dunstan" <andrew@dunslane.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.

Sadly one effect of the 1-byte header varlenas is that the position of the
first varlena can't be cached any more. That's because its alignment depends
on whether you're storing a short varlena or a full 4-byte varlena.

Currently there's an exception for the first column of the table since that's
always at offset 0. We could add another exception and cache the first varlena
if it happens to land on an intaligned offset without any extra alignment. I'm
not sure if that pays for itself or not though. It still only helps 25% of the
time and only for the first varlena so it doesn't seem terribly important.

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Column storage positions
Next
From: "Matthew T. O'Connor"
Date:
Subject: Re: autovacuum next steps, take 2