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-Wzm2J6ST0nzSdCziYxmzSO1wH-dq3KzXUMy6huu9TrYKaw@mail.gmail.com
Whole thread Raw
In response to Re: Pathological performance when inserting many NULLs into a uniqueindex  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Pathological performance when inserting many NULLs into a unique index
List pgsql-hackers
On Thu, Apr 18, 2019 at 5:46 PM Michael Paquier <michael@paquier.xyz> wrote:
> Adding an open item is adapted, nice you found this issue.  Testing on
> my laptop with v11, the non-NULL case takes 5s and the NULL case 6s.
> On HEAD, the non-NULL case takes 6s, and the NULL case takes...  I
> just gave up and cancelled it :)

This was one of those things that occurred to me out of the blue.

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.

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Race conditions with checkpointer and shutdown
Next
From: Etsuro Fujita
Date:
Subject: Re: bug in update tuple routing with foreign partitions