On 9 August 2012 15:27, Tom Lane wrote:
Simon Riggs <simon@2ndQuadrant.com> 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.
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

Search Discussions

Discussion Posts


Follow ups

Related Discussions

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



site design / logo © 2021 Grokbase