Re: Faster inserts with mostly-monotonically increasing values - Mailing list pgsql-hackers

From Claudio Freire
Subject Re: Faster inserts with mostly-monotonically increasing values
Date
Msg-id CAGTBQpYs2KY5srVVUFOBLUMwuLMTXvJRNOAmJ7iW7GXN4Q7DJw@mail.gmail.com
Whole thread Raw
In response to Re: Faster inserts with mostly-monotonically increasing values  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: Faster inserts with mostly-monotonically increasing values  (Peter Geoghegan <pg@bowt.ie>)
List pgsql-hackers
On Sun, Dec 31, 2017 at 8:06 AM, Peter Geoghegan <pg@bowt.ie> wrote:
> I also have my
> doubts about unique index enforcement remaining correct with the patch
> when there are many physical duplicates, to the extent that more than
> a single leaf page is needed for a single value.

given...

+        if (P_ISLEAF(lpageop) && P_RIGHTMOST(lpageop) &&
+            !P_INCOMPLETE_SPLIT(lpageop) &&
+            !P_IGNORE(lpageop) &&
+            (PageGetFreeSpace(page) > itemsz) &&
+            _bt_compare(rel, natts, itup_scankey, page,
PageGetMaxOffsetNumber(page)) > 0)

The key there is strictly greater than the rightmost key. As such, it
must precede the first page with an equal key, and since it's the
rightmost page... there's no such key. But if there was, the check for
uniqueness only needs the insert point to point to the first such
page, and this guarantees it.

You could allow for some slack, by comparing against the leftmost key
instead. You just need to know whether the key fits in the page. Then,
the insert can proceed as usual, doing the binsearch to find the
proper insertion point, etc.

That would allow this case to be applied not only to perfectly
monotonic sequences, but for nearly monotonic ones as well (think
timestamps).


pgsql-hackers by date:

Previous
From: Vik Fearing
Date:
Subject: Re: Sample values for pg_stat_statements
Next
From: Tomas Vondra
Date:
Subject: Re: Hash Joins vs. Bloom Filters / take 2