Re: WIP: Covering + unique indexes.

Поиск
Список
Период
Сортировка
Искать
От
Anastasia Lubennikova
Тема
Re: WIP: Covering + unique indexes.
Дата
Msg-id
5707A7FD.6080105@postgrespro.ru
Ответ на
Список
Дерево обсуждения
Re: WIP: Covering + unique indexes. Anastasia Lubennikova <a.lubennikova@postgrespro.ru>
08.04.2016 15:06, Teodor Sigaev:
>> On Wed, Apr 6, 2016 at 1:50 PM, Peter Geoghegan  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

В списке pgsql-hackers по дате отправления
От: Michael Paquier
Дата:
От: Jesper Pedersen
Дата:
FAQ