Re: Allow to specify #columns in heap/index_form_tuple

On Fri, Mar 31, 2017 at 2:11 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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).

I've implemented a rough prototype of suffix truncation, that seems to
work well enough, and keeps amcheck happy, and I base my remarks on
the experience of writing that prototype. Using the NULL bitmap this
way was the first thing I tried.

--
Peter Geoghegan