Re: WIP: Covering + unique indexes.

On Tue, Mar 27, 2018 at 10:07 AM, Teodor Sigaev <teodor(at)sigaev(dot)ru> wrote:
> Storing number of attributes in now unused t_tid seems to me not so good
> idea. a) it could (and suppose, should) separate patch, at least it's not
> directly connected to covering patch, it could be added even before covering
> patch.

I think that we should do that first. It's not very hard.

> b) I don't like an idea to limiting usage of that field if we can do not
> that. Future usage could use it, for example, for different compression
> technics or something else.

The extra status bits that this would leave within the offset field
can be used for that in the future.

>> * It makes diagnosing issues in the field quite a bit easier. Tools
>> like pg_filedump can do the right thing (Tom mentioned pg_filedump and
>> amcheck specifically). The nbtree IndexTuple format should not need to
>> be interpreted in a context-sensitive way, if we can avoid it.
>
> Both pg_filedump and amcheck could correclty parse any tuple based on
> BTP_LEAF flags and length of tuple.

amcheck doesn't just care about the length of the tuple. It would have
to rely on catalog metadata about this being an INCLUDE index.

--
Peter Geoghegan