From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | "Andrey V(dot) Lepikhov" <a(dot)lepikhov(at)postgrespro(dot)ru> |
Cc: | Юрий Соколов <funny(dot)falcon(at)gmail(dot)com>, PostgreSQL-Dev <pgsql-hackers(at)postgresql(dot)org>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
Subject: | Re: [WIP] [B-Tree] Retail IndexTuple deletion |
Date: | 2018-07-12 19:00:39 |
Message-ID: | CAH2-Wzm2SG40Hp2nYMzqkKXz3-B9bxSM1N02bGNkft4djwYm7A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jul 3, 2018 at 5:17 AM, Andrey V. Lepikhov
<a(dot)lepikhov(at)postgrespro(dot)ru> wrote:
> Done.
> Attachment contains an update for use v.2 of the 'Ensure nbtree leaf tuple
> keys are always unique' patch.
My v3 is still pending, but is now a lot better than v2. There were
bugs in v2 that were fixed.
One area that might be worth investigating is retail index tuple
deletion performed within the executor in the event of non-HOT
updates. Maybe LP_REDIRECT could be repurposed to mean "ghost record",
at least in unique index tuples with no NULL values. The idea is that
MVCC index scans can skip over those if they've already found a
visible tuple with the same value. Also, when there was about to be a
page split, they could be treated a little bit like LP_DEAD items. Of
course, the ghost bit would have to be treated as a hint that could be
"wrong" (e.g. because the transaction hasn't committed yet), so you'd
have to go to the heap in the context of a page split, to double
check. Also, you'd need heuristics that let you give up on this
strategy when it didn't help.
I think that this could work well enough for OLTP workloads, and might
be more future-proof than doing it in VACUUM. Though, of course, it's
still very complicated.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Robbie Harwood | 2018-07-12 19:07:33 | Re: [HACKERS] [PATCH] WIP Add ALWAYS DEFERRED option for constraints |
Previous Message | Tom Lane | 2018-07-12 18:52:09 | Re: Cache invalidation after authentication (on-the-fly role creation) |