Subject: Re: WIP: Covering + unique indexes.
To: Peter Geoghegan <pg@bowt.ie>,
 Alexander Korotkov <a.korotkov@postgrespro.ru>
Cc: Anastasia Lubennikova <a.lubennikova@postgrespro.ru>,
 Thomas Munro <thomas.munro@enterprisedb.com>,
 Andrey Borodin <x4mmm@yandex-team.ru>,
 PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
 Anastasia Lubennikova <lubennikovaav@gmail.com>
References: <56168952.4010101@postgrespro.ru>
 <7FEB0867-F4F2-4F18-8AA9-7BAA0BB32868@yandex-team.ru>
 <151654594496.23710.401435331419974842.pgcf@coridan.postgresql.org>
 <1d2b6e12-9e1c-8df5-fdd6-4d20d3791b86@postgrespro.ru>
 <CAEepm=2gh3nKi2u18i4r=TLhMyZf6guWSwmrHEcwm7dyJahnow@mail.gmail.com>
 <b91d08de-db32-490d-6287-5c47b506767c@postgrespro.ru>
 <CAEepm=07Lry2eH+ORvnGn=zTrSQCR0oVgz_0JNTQKUXdzaAszg@mail.gmail.com>
 <78ca1586-647c-e159-ebf3-30957e270c66@postgrespro.ru>
 <CAPpHfdvPv8BJVNygLrNkyQDUcyKFhsa25epr0m3cExzxmek8VA@mail.gmail.com>
 <CAPpHfdsRDDQ4sqpb2+igiRok3r_EVZ0GJNC+nC98-gxW02MGaQ@mail.gmail.com>
 <CAH2-WzkHH1E7MR08zMKpoHEp8g=0xoTNwCOLt8B_ETP4SeGi=A@mail.gmail.com>
From: Teodor Sigaev <teodor@sigaev.ru>
Message-ID: <7789d9f5-3fca-1531-e771-932cbcbe91e3@sigaev.ru>
Date: Tue, 27 Mar 2018 20:07:34 +0300
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101
 Firefox/52.0 SeaMonkey/2.49.1
MIME-Version: 1.0
In-Reply-To: 
 <CAH2-WzkHH1E7MR08zMKpoHEp8g=0xoTNwCOLt8B_ETP4SeGi=A@mail.gmail.com>
Content-Type: text/plain; charset=KOI8-R; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

> The last time I looked at this patch, in April 2017, I made the point
> that we should add something like an "nattributes" argument to
> index_truncate_tuple() [1], rather than always using
> IndexRelationGetNumberOfKeyAttributes() within index_truncate_tuple().
Agree, it looks logical because a) reading code will be simpler b) function will 
be use for any future usage.

> Having this index_truncate_tuple() "nattributes" argument, and storing
> the number of attributes directly improves quite a lot of things:

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

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

-- 
Teodor Sigaev                                   E-mail: teodor@sigaev.ru
                                                    WWW: http://www.sigaev.ru/