Re: WIP: Covering + unique indexes.
От | Anastasia Lubennikova |
---|---|
Тема | Re: WIP: Covering + unique indexes. |
Дата | |
Msg-id | 5707C8A0.1030208@postgrespro.ru обсуждение исходный текст |
Ответ на | Re: WIP: Covering + unique indexes. (Anastasia Lubennikova <a.lubennikova@postgrespro.ru>) |
Ответы |
Re: WIP: Covering + unique indexes.
|
Список | pgsql-hackers |
08.04.2016 15:45, Anastasia Lubennikova: > 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 One more improvement - note about expressions into documentation. -- Anastasia Lubennikova Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
Вложения
В списке pgsql-hackers по дате отправления: