On 9 August 2012 15:27, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Simon Riggs <simon@2ndQuadrant.com> writes:
>> On 17 April 2012 17:22, Jameison Martin <jameisonb@yahoo.com> 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.
That wasn't my understanding, but that could be wrong.
> 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.
Large numbers of columns are surprisingly common and tables with large
numbers of columns usually have many rows as well. So this doesn't
matter for most tables, but the few that need this can often represent
>80% of database volume, so it is important.
(Next challenge is how to cope with 1000s of columns.)
> 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.
"One simple tweak" works for me.
-- Simon Riggs http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services