Re: Allow to specify #columns in heap/index_form_tuple

On Mar 31, 2017 2:17 PM, "Peter Geoghegan" <pg(at)bowt(dot)ie> wrote:

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).

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.
--
Peter Geoghegan
(Sent from my phone)