Re: WIP: Covering + unique indexes.
От | Anastasia Lubennikova |
---|---|
Тема | Re: WIP: Covering + unique indexes. |
Дата | |
Msg-id | bb4b24dd-eb80-97c8-5cb1-63dca80c8ec5@postgrespro.ru обсуждение исходный текст |
Ответ на | Re: WIP: Covering + unique indexes. (Andres Freund <andres@anarazel.de>) |
Список | pgsql-hackers |
31.03.2017 20:47, Andres Freund:
The function is called not that often. Only once per page split for indexes with included columns.
Doesn't look like dramatic overhead. So I decided that a wrapper function would be more appropriate than refactoring of all index_form_tuple() calls.
But index_form_tuple_extended() looks like a better solution.
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.
The function is called not that often. Only once per page split for indexes with included columns.
Doesn't look like dramatic overhead. So I decided that a wrapper function would be more appropriate than refactoring of all index_form_tuple() calls.
But index_form_tuple_extended() looks like a better solution.
-- Anastasia Lubennikova Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
В списке pgsql-hackers по дате отправления: