Re: WIP: Covering + unique indexes.
От | Anastasia Lubennikova |
---|---|
Тема | Re: WIP: Covering + unique indexes. |
Дата | |
Msg-id | 5707A7FD.6080105@postgrespro.ru обсуждение исходный текст |
Ответ на | Re: WIP: Covering + unique indexes. (Teodor Sigaev <teodor@sigaev.ru>) |
Ответы |
Re: WIP: Covering + unique indexes.
|
Список | 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
Вложения
В списке pgsql-hackers по дате отправления: