Re: Column storage positions

"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.

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