Re: Pathological performance when inserting many NULLs into a unique index - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Pathological performance when inserting many NULLs into a unique index
Date
Msg-id CAH2-WzkR50K1V7MVFVckAoFi2xwR4TtaicefxCgcHys98yMqtA@mail.gmail.com
Whole thread Raw
In response to Re: Pathological performance when inserting many NULLs into a unique index  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: Pathological performance when inserting many NULLs into a unique index
List 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

Attachment

pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: [PATCH v20] GSSAPI encryption support
Next
From: Robert Haas
Date:
Subject: Re: block-level incremental backup