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

From Tom Lane
Subject Re: patch submission: truncate trailing nulls from heap rows to reduce the size of the null bitmap [Review]
Date
Msg-id 14877.1359079336@sss.pgh.pa.us
Whole thread Raw
In response to Re: patch submission: truncate trailing nulls from heap rows to reduce the size of the null bitmap [Review]  (Greg Stark <stark@mit.edu>)
List pgsql-hackers
Greg Stark <stark@mit.edu> writes:
> That said I don't know just how common that usage pattern is. And I'm
> not sure how many of those people would be able to arrange for the
> null columns to land at the end of the row.

Obviously, they can't arrange that all the time (else their trailing
columns are unnecessary).  It'd have to be something like ordering the
columns in descending probability of being not-null --- and unless the
later columns *all* have very small probability of being not-null,
you're not gonna win much.  Much as I hate to suggest that somebody
consider EAV-like storage, one does have to wonder whether a schema
like that doesn't need redesign more than it needs an implementation
tweak.

> It's a bit frustrating because it does seem like if it had been
> written this way to begin with nobody would every have questioned
> whether it was a good idea and nobody would ever have suggested
> ripping it out.

True, but we'd also have a much higher probability that there aren't
latent bugs because of expectations that t_natts is trustworthy.
It's the cost of getting from here to there that's scaring me.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: Re: patch submission: truncate trailing nulls from heap rows to reduce the size of the null bitmap [Review]
Next
From: Craig Ringer
Date:
Subject: Re: proposal: fix corner use case of variadic fuctions usage