Re: WIP: Covering + unique indexes.

From: Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru>
To: Teodor Sigaev <teodor(at)sigaev(dot)ru>
Cc: Peter Geoghegan <pg(at)heroku(dot)com>, David Steele <david(at)pgmasters(dot)net>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
Subject: Re: WIP: Covering + unique indexes.
Date: 2016-04-08 12:45:49
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

08.04.2016 15:06, Teodor Sigaev:
>> On Wed, Apr 6, 2016 at 1:50 PM, Peter Geoghegan <pg(at)heroku(dot)com> wrote:
>>> Personally, I like documenting assertions, and will sometimes write
>>> assertions that the compiler could easily optimize away. Maybe going
>>> *that* far is more a matter of personal style, but I think an
>>> assertion about the new index tuple size being <= the old one is just
>>> a good idea. It's not about a problem in your code at all.
>> You should make index_truncate_tuple()/index_reform_tuple() promise to
>> always do this in its comments/contract with caller as part of this,
>> IMV.
> Some notices:
> - index_truncate_tuple(Relation idxrel, IndexTuple olditup, int indnatts,
> int indnkeyatts)
> Why we need indnatts/indnkeyatts? They are presented in idxrel struct
> already
> - follow code where index_truncate_tuple() is called, it should never
> called in
> case where indnatts == indnkeyatts. So, indnkeyatts should be
> strictly less
> than indnatts, pls, change assertion. If they are equal the this
> function
> becomes complicated variant of CopyIndexTuple()

Good point. These attributes seem to be there since previous versions of
the function.
But now they are definitely unnecessary. Updated patch is attached

Anastasia Lubennikova
Postgres Professional:
The Russian Postgres Company

Attachment Content-Type Size
including_columns_10.1.patch text/x-patch 133.7 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Jesper Pedersen 2016-04-08 12:49:16 Re: Speedup twophase transactions
Previous Message Michael Paquier 2016-04-08 12:44:55 Re: Lower msvc build verbosity level