Simon Riggs writes:
On 17 April 2012 17:22, Jameison Martin wrote:
The following patch truncates trailing null attributes from heap rows to
reduce the size of the row bitmap.
This is an interesting patch, but its has had various comments made about it.
When I look at this I see that it would change the NULL bitmap for all
existing rows, which means it forces a complete unload/reload of data.
Huh? I thought it would only change how *new* tuples were stored.
Old tuples ought to continue to work fine.

I'm not really convinced that it's a good idea in the larger scheme
of things --- your point in a nearby thread that micro-optimizing
storage space at the expense of all else is not good engineering
applies here. But I don't see that it forces data reload. Or if
it does, that should be easily fixable.
... Have another flag which indicates
when a partial trailing col trimmed NULL bitmap is in use.
That might be useful for forensic purposes, but on the whole I suspect
it's just added complexity (and eating up a valuable infomask bit)
for relatively little gain.
... decide whether a table will benefit from full or partial bitmap and
set that in the tupledesc. That way the tupledesc will show
heap_form_tuple which kind of null bitmap is preferred for new tuples.
That preference might be settable by user on or off, but the default
would be for postgres to decide that for us based upon null stats etc,
which we would decide at ANALYZE time.
And that seems like huge overcomplication. I think we could probably
do fine with some very simple fixed policy, like "don't bother with
this for tables of less than N columns", where N is maybe 64 or so
and chosen to match the MAXALIGN boundary where there actually could
be some savings from trimming the null bitmap.

(Note: I've not read the patch, so maybe Jameison already did something
of the sort.)

regards, tom lane

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 24 of 28 | next ›
Discussion Overview
grouppgsql-hackers @
postedApr 17, '12 at 4:23p
activeAug 10, '12 at 12:06a



site design / logo © 2021 Grokbase