From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Victor Yegorov <vyegorov(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Deleting older versions in unique indexes to avoid page splits |
Date: | 2020-11-30 19:50:58 |
Message-ID: | CAH2-WzmX21q+en6g0aH4VfUCNk+QODWA6hrqhga0Ym06tHiHgA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Nov 25, 2020 at 10:41 AM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> We have promising tuples for bottom-up deletion. Why not have
> "promising heap blocks" for traditional LP_DEAD index tuple deletion?
> Or if you prefer, we can consider index tuples that *don't* have their
> LP_DEAD bits set already but happen to point to the *same heap block*
> as other tuples that *do* have their LP_DEAD bits set promising. (The
> tuples with their LP_DEAD bits set are not just promising -- they're
> already a sure thing.)
>
> This means that traditional LP_DEAD deletion is now slightly more
> speculative in one way (it speculates about what is likely to be true
> using heuristics). But it's much less speculative than bottom-up index
> deletion. We are required to visit these heap blocks anyway, since a
> call to _bt_delitems_delete() for LP_DEAD deletion must already call
> table_compute_xid_horizon_for_tuples(), which has to access the blocks
> to get a latestRemovedXid for the WAL record.
>
> The only thing that we have to lose here is a few CPU cycles to find
> extra TIDs to consider. We'll visit exactly the same number of heap
> blocks as before. (Actually, _bt_delitems_delete() does not have to do
> that in all cases, actually, but it has to do it with a logged table
> with wal_level >= replica, which is the vast majority of cases in
> practice.)
>
> This means that traditional LP_DEAD deletion reuses some of the
> bottom-up index deletion infrastructure. So maybe nbtree never calls
> table_compute_xid_horizon_for_tuples() now, since everything goes
> through the new heapam stuff instead (which knows how to check extra
> TIDs that might not be dead at all).
Attached is v10, which has this LP_DEAD deletion enhancement I
described. (It also fixed bitrot -- v9 no longer applies.)
This revision does a little refactoring to make this possible. Now
there is less new code in nbtdedup.c, and more code in nbtpage.c,
because some of the logic used by bottom-up deletion has been
generalized (in order to be used by the new-to-v10 LP_DEAD deletion
enhancement).
Other than that, no big changes between this v10 and v9. Just
polishing and refactoring. I decided to make it mandatory for tableams
to support the new interface that heapam implements, since it's hardly
okay for them to not allow LP_DEAD deletion in nbtree (which is what
making supporting the interface optional would imply, given the
LP_DEAD changes). So now the heapam and tableam changes are including
in one patch/commit, which is to be applied first among patches in the
series.
--
Peter Geoghegan
Attachment | Content-Type | Size |
---|---|---|
v10-0001-Teach-heapam-to-support-bottom-up-index-deletion.patch | application/octet-stream | 34.2 KB |
v10-0002-Pass-down-logically-unchanged-index-hint.patch | application/octet-stream | 29.4 KB |
v10-0003-Teach-nbtree-to-use-bottom-up-index-deletion.patch | application/octet-stream | 89.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2020-11-30 19:54:39 | {CREATE INDEX, REINDEX} CONCURRENTLY improvements |
Previous Message | Anastasia Lubennikova | 2020-11-30 19:45:31 | Re: Change JOIN tutorial to focus more on explicit joins |