Re: Using indexUnchanged with nbtree - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Using indexUnchanged with nbtree
Date
Msg-id CAH2-WzmQ7W5Wz0mrQ5aXYrg-cB2qOYk_emRd_aT0rRXBMb1A+w@mail.gmail.com
Whole thread Raw
In response to Using indexUnchanged with nbtree  (Simon Riggs <simon.riggs@enterprisedb.com>)
Responses Re: Using indexUnchanged with nbtree
List pgsql-hackers
On Mon, Jun 21, 2021 at 5:31 AM Simon Riggs
<simon.riggs@enterprisedb.com> wrote:
> Seems like we can skip the uniqueness check if indexUnchanged, which
> will speed up non-HOT UPDATEs on tables with B-Trees.

I thought about doing this myself. Never got as far as thinking about
the correctness implications in detail.

One thing that I'm concerned about is LP_DEAD bit setting inside
_bt_check_unique(), which isn't going to take place when the
optimization from the patch is applied. That definitely used to be way
more important than kill_prior_tuple-based LP_DEAD bit setting, which
has real problems with non-HOT updates [1]. _bt_check_unique() clearly
makes up for that in the case of unique indexes, at least for many
years.

On the other hand my thinking here might well be outdated, because of
course bottom-up index deletion exists now. You're using
indexUnchanged here, which is used to trigger bottom-up index deletion
passes. Maybe that's enough for it to not matter now, meaning that the
LP_DEAD bit stuff is not a real blocker here. Offhand I'm quite
unsure.

[1]
https://www.postgresql.org/message-id/flat/CAH2-Wz%3DSfAKVMv1x9Jh19EJ8am8TZn9f-yECipS9HrrRqSswnA%40mail.gmail.com#b20ead9675225f12b6a80e53e19eed9d
-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Decoding speculative insert with toast leaks memory
Next
From: Alvaro Herrera
Date:
Subject: Re: Pipeline mode and PQpipelineSync()