pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Teodor Sigaev <teodor@sigaev.ru>
To: Peter Geoghegan <pg@bowt.ie>
To: Alexander Korotkov <a.korotkov@postgrespro.ru>
Cc: Anastasia Lubennikova <a.lubennikova@postgrespro.ru>
Cc: Thomas Munro <thomas.munro@enterprisedb.com>
Cc: Andrey Borodin <x4mmm@yandex-team.ru>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Cc: Anastasia Lubennikova <lubennikovaav@gmail.com>
Subject: Re: WIP: Covering + unique indexes.
Date: Tue, 27 Mar 2018 20:07:34 +0300
Message-ID: <7789d9f5-3fca-1531-e771-932cbcbe91e3@sigaev.ru> (raw)
In-Reply-To: <CAH2-WzkHH1E7MR08zMKpoHEp8g=0xoTNwCOLt8B_ETP4SeGi=A@mail.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>

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




view thread (217+ messages)  latest in thread

Message-ID: <7789d9f5-3fca-1531-e771-932cbcbe91e3@sigaev.ru>
Permalink:  ../7789d9f5-3fca-1531-e771-932cbcbe91e3@sigaev.ru/
Also on:    postgresql.org/message-id/7789d9f5-3fca-1531-e771-932cbcbe91e3@sigaev.ru

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: teodor@sigaev.ru, pg@bowt.ie, a.korotkov@postgrespro.ru, a.lubennikova@postgrespro.ru, thomas.munro@enterprisedb.com, x4mmm@yandex-team.ru, pgsql-hackers@lists.postgresql.org, lubennikovaav@gmail.com
  Subject: Re: WIP: Covering + unique indexes.
  In-Reply-To: <7789d9f5-3fca-1531-e771-932cbcbe91e3@sigaev.ru>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox