Re: Proposal for Null Bitmap Optimization(for TrailingNULLs)

"Simon Riggs" <simon(at)2ndquadrant(dot)com> writes:

> On Mon, 2007-12-17 at 08:47 -0500, Andrew Dunstan wrote:
>
>> This strikes me as such a corner case that it's likely not to be worth it.
>>
>> If you really want to save space along these lines, one better place to
>> start might be mutable with column ordering - see
>> http://archives.postgresql.org/pgsql-hackers/2006-12/msg00983.php . That
>> would mean that we would be able to move nullable columns physically to
>> the tail which in turn might help this suggestion have more effect.

That would only be one factor in deciding how to arrange columns but you have
to decide what order to store them when you're creating the table. You can't
move them around tuple by tuple. Only when rewriting the whole table would you
be able to move them around.

My first thought on how to arrange the columns would be:

fixed-size not nullable
fixed-size nullable
all variable-sized

With this additional tweak you would want to change that to:

fixed-size not nullable
fixed-size nullable
variable-size not nullable
variable-size nullable

I don't think you would want to store variable-sized not nullable columns
before fixed-sized nullable columns because in the cases where they're not
null you want to be able to use the cached offsets.

There could be some other factors to the decision when it comes to alignment
though. It might be worth putting a nullable column before a not null column
if it lets you fix the alignment and it's rarely actually null.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's PostGIS support!