From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Simon Riggs <simon(dot)riggs(at)enterprisedb(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Using indexUnchanged with nbtree |
Date: | 2021-06-25 01:33:59 |
Message-ID: | CAH2-Wzk=wDTQkGziWSaJy67hVhG9_zh7RP6AkAr+tubtGfo1Jw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jun 24, 2021 at 5:39 AM Simon Riggs
<simon(dot)riggs(at)enterprisedb(dot)com> wrote:
> This case occurs when we are doing non-HOT UPDATEs. That command is
> searched, so the scan will already have touched the heap and almost
> certainly the index also, setting any LP_DEAD bits already in the most
> frequent case.
But it won't, because the restriction that I described with non-HOT
updates in kill_prior_tuple in that old thread I linked to. This has
been the case since commit 2ed5b87f96d from Postgres 9.5. This
probably should probably be fixed, somehow, but for now I don't think
you can assume anything about LP_DEAD bits being set -- they're
clearly not set with a non-HOT update when the UPDATE's ModifyTable
node is fed by a scan of the same index (unless we reach
_bt_check_unique() because it's a unique index).
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2021-06-25 01:36:53 | Re: pgsql: Fix pattern matching logic for logs in TAP tests of pgbench |
Previous Message | Masahiro Ikeda | 2021-06-25 01:33:23 | Re: Transactions involving multiple postgres foreign servers, take 2 |