Re: Pathological performance when inserting many NULLs into a unique index

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: Pathological performance when inserting many NULLs into a unique index
Дата
Msg-id CAH2-WzkR50K1V7MVFVckAoFi2xwR4TtaicefxCgcHys98yMqtA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Pathological performance when inserting many NULLs into a unique index  (Peter Geoghegan <pg@bowt.ie>)
Ответы Re: Pathological performance when inserting many NULLs into a unique index  (Peter Geoghegan <pg@bowt.ie>)
Список pgsql-hackers
On Thu, Apr 18, 2019 at 8:13 PM Peter Geoghegan <pg@bowt.ie> wrote:
> It just occurred to me that the final patch will need to be more
> careful about non-key attributes in INCLUDE indexes. It's not okay for
> it to avoid calling _bt_check_unique() just because a non-key
> attribute was NULL. It should only do that when a key attribute is
> NULL.

Attached revision does it that way, specifically by adding a new field
to the insertion scankey struct (BTScanInsertData). The field is
filled-in when initializing an insertion scankey in the usual way. I
was able to reuse alignment padding for the new field, so there is no
additional space overhead on Linux x86-64.

This is a bit more complicated than v1, but there is still an overall
net reduction in overall complexity (and in LOC). I'm going to commit
this early next week, barring any objections, and assuming I don't
think of any more problems between now and then.
--
Peter Geoghegan

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: [PATCH v20] GSSAPI encryption support
Следующее
От: Robert Haas
Дата:
Сообщение: Re: block-level incremental backup