Re: Using indexUnchanged with nbtree

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: Using indexUnchanged with nbtree
Дата
Msg-id CAH2-WzmQ7W5Wz0mrQ5aXYrg-cB2qOYk_emRd_aT0rRXBMb1A+w@mail.gmail.com
обсуждение исходный текст
Ответ на Using indexUnchanged with nbtree  (Simon Riggs <simon.riggs@enterprisedb.com>)
Ответы Re: Using indexUnchanged with nbtree  (Simon Riggs <simon.riggs@enterprisedb.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Decoding speculative insert with toast leaks memory
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Pipeline mode and PQpipelineSync()