On Mar 31, 2017 2:17 PM, "Peter Geoghegan" <pg@bowt.ie> wrote:
On Fri, Mar 31, 2017 at 2:11 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> The patch does actually store truncated/key-only tuples in the hi keys / >> non-leaf-nodes, which don't need the "included" columns. > > Hm. Since index tuples lack any means of indicating the actual number > of columns included (ie there's no equivalent of the natts field that > exists in HeapTupleHeaders), I think that this is an unreasonably > dangerous design. It'd be better to store nulls for the missing > fields. That would force a null bitmap to be included whether or > not there were nulls in the key columns, but if we're only doing it > once per page that doesn't seem like much cost.
We're doing it once per page for the leaf page high key, but that's used as the downlink in the second phase of a B-Tree page split -- it's directly copied. So, including a NULL bitmap would make Anastasia's patch significantly less useful, since that now has to be in every internal page, and might imply that you end up with less fan-in much of the time (e.g., int4 attribute is truncated from the end relative to leaf IndexTuple format).
BTW, what about the 1/3 of a page restriction on tuple size?
I think that truncation has to strictly guarantee that the resulting tuple will be no larger than the original. Otherwise, you get into trouble here. But, that's still not my main objection to using the null bitmap.
