Re: WIP: Covering + unique indexes.
От | Andres Freund |
---|---|
Тема | Re: WIP: Covering + unique indexes. |
Дата | |
Msg-id | 20170331174728.4hpwklu46qwcrfwa@alap3.anarazel.de обсуждение исходный текст |
Ответ на | WIP: Covering + unique indexes. (Anastasia Lubennikova <a.lubennikova@postgrespro.ru>) |
Ответы |
Re: WIP: Covering + unique indexes.
|
Список | pgsql-hackers |
On 2017-03-31 20:40:59 +0300, Anastasia Lubennikova wrote: > 30.03.2017 22:11, Andres Freund > > Any objection from reviewers to push both patches? > > First of all, I want to thank you and Robert for reviewing this patch. > Your expertise in postgres subsystems is really necessary for features like > this. > I just wonder, why don't you share your thoughts and doubts till the "last > call". Because there's a lot of other patches? I only looked because Teodor announced he was thinking about committing - I just don't have the energy to look at all patches before they're ready to commit. Unfortunatly "ready-for-committer" is very frequently not actually that :( > > Maybe it would be better to modify index_form_tuple() to accept a new > > argument with a number of attributes, then you can just Assert that > > this number is never higher than the number of attributes in the > > TupleDesc. > Good point. > I agree that this function is a bit strange. I have to set > tupdesc->nattrs to support compatibility with index_form_tuple(). > I didn't want to add neither a new field to tupledesc nor a new > parameter to index_form_tuple(), because they are used widely. > > > But I haven't considered the possibility of index_form_tuple() failure. > Fixed in this version of the patch. Now it creates a copy of tupledesc to > pass it to index_form_tuple. That seems like it'd actually be a noticeable increase in memory allocator overhead. I think we should just add (as just proposed in separate thread), a _extended version of it that allows to specify the number of columns. - Andres
В списке pgsql-hackers по дате отправления: