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

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Pathological performance when inserting many NULLs into a unique index
Date: 2019-04-19 03:13:44
Message-ID: CAH2-Wzm2J6ST0nzSdCziYxmzSO1wH-dq3KzXUMy6huu9TrYKaw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Apr 18, 2019 at 5:46 PM Michael Paquier <michael(at)paquier(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Etsuro Fujita 2019-04-19 03:15:11 Re: bug in update tuple routing with foreign partitions
Previous Message Tom Lane 2019-04-19 02:57:45 Re: Race conditions with checkpointer and shutdown