Re: Allow to specify #columns in heap/index_form_tuple

On Fri, Mar 31, 2017 at 2:32 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I think you are failing to get the point. I am not on about whether
> we need a few bytes more or less, I am on about whether the patch
> even works. As an example, it's quite unclear what the width of
> such an index tuple's nulls bitmap will be if it exists, and there
> certainly will be cases where it must exist because of nulls in the
> keys columns. I also think we're setting up a situation where tools
> like amcheck and pg_filedump are going to be unable to cope, because
> figuring out what a particular tuple contains is going to require context
> they haven't got. It just seems way too dangerous.

Why wouldn't they have the context? I think that we can use the page
offset for internal items to indicate the number of attributes that
were truncated in each case. That field is currently unused in all
relevant cases (for "separator" IndexTuples). This wouldn't be the
first time we put a magic value into an item pointer offset. That
detail would be redundant for Anastasia's patch, but we can imagine a
future in which that isn't the case.

There is a free bit within IndexTupleData.t_info that could indicate
that this is what happened. I am not going to comment on how dangerous
any of this may or may not be just yet, but FWIW I think it would be
worth using that bit to allow suffix truncation to work. Suffix
truncation is a widely used technique, that Anastasia's patch happens
to be a special case of. It's a technique that is almost as old as
B-Trees themselves.

The use of a dedicated bit probably wouldn't be necessary, but perhaps
it makes things safer for the patch.

--
Peter Geoghegan