Re: patch submission: truncate trailing nulls from heap rows to reduce the size of the null bitmap [Review]

On Mon, Jun 24, 2013 at 4:50 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> The point of what I was suggesting isn't to conserve storage, but to
> reduce downtime during a schema change.  Remember that a rewriting ALTER
> TABLE locks everyone out of that table for a long time.

Sure, I understand.  As Josh says, though, it'd still be potentially
quite surprising.

>> So, Tom, how's that pluggable storage format coming?  :-)
>
> Well, actually, it's looking to me like heap_form_tuple will be
> underneath the API cut, because alternate storage managers will probably
> have other tuple storage formats --- column stores being the poster
> child here, but in any case the tuple header format is very unlikely
> to be universal.

I've had the same thought.  Unfortunately, there are a lot of things -
like the TupleTableSlot abstraction - that are fairly deeply in bed
with the format used by our current heap AM; so we might be imposing a
performance overhead for anyone who uses some other representation.
Unless you have some idea how to avoid that?

> Which means that whether this patch gets applied to mainline is going
> to be moot for Salesforce's purposes; they will certainly want the
> equivalent logic in their storage code, because they've got tables with
> many hundreds of mostly-null columns, but whether heap_form_tuple acts
> this way or not won't affect them.

OK.

> So unless we consider that many-hundreds-of-columns is a design center
> for general purpose use of Postgres, we should be evaluating this patch
> strictly on its usefulness for more typical table widths.  And my take
> on that is that (1) lots of columns isn't our design center (for the
> reasons you mentioned among others), and (2) the case for the patch
> looks pretty weak otherwise.

I guess I have yet to be convinced that it really hurts anything.
Your example seems fairly hypothetical and could easily be something
no one ever implements.  I don't feel terribly strongly that we need
to take this patch, and I don't really care that much whether we do or
not; I'm just not really convinced there's any actual evidence that we
shouldn't.  The standard isn't that it's got to make something really
important better; it's just got to make something better without
making anything more important worse.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company