Jameison Martin <jameisonb@yahoo.com> writes:
> The following patch truncates trailing null attributes from heap rows to reduce the size of the row bitmap.
This has been discussed before, but it always seemed that the
cost-benefit ratio was exceedingly questionable. You don't get any
savings whatsoever unless you reduce the size of the null bitmap across
a MAXALIGN boundary, which more and more often is 64 bits, so that the
frequency with which the optimization wins anything doesn't look likely
to be that high. And on the other side of the coin, you're adding
cycles to every single tuple-construction operation to make this work.
The introduction of bugs doesn't seem improbable either. (Just because
tuples in user tables might have unexpected natts values doesn't mean
that the code is, or should be, prepared to tolerate that in system
tables or plan-constructed tuples.)
So what I'd like to see is some concrete test results proving that this
is a net win, or at least not a net loss, for typical cases. Just
asserting that it might be a win for certain usage patterns doesn't do
it for me.
regards, tom lane
