Re: WIP: Covering + unique indexes. - Mailing list pgsql-hackers

From Anastasia Lubennikova
Subject Re: WIP: Covering + unique indexes.
Date
Msg-id 5707A7FD.6080105@postgrespro.ru
Whole thread Raw
In response to Re: WIP: Covering + unique indexes.  (Teodor Sigaev <teodor@sigaev.ru>)
Responses Re: WIP: Covering + unique indexes.
List pgsql-hackers
08.04.2016 15:06, Teodor Sigaev:
>> On Wed, Apr 6, 2016 at 1:50 PM, Peter Geoghegan <pg@heroku.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: http://www.postgrespro.com
The Russian Postgres Company


Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Lower msvc build verbosity level
Next
From: Jesper Pedersen
Date:
Subject: Re: Speedup twophase transactions