On Wed, Jun 23, 2021 at 5:17 PM Peter Geoghegan <pg@bowt.ie> wrote:
>
> 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.
You're right that skipping the check might also skip killing a prior
row version, but it doesn't prevent later scans from killing them, so
there is no correctness aspect to that.
In the case of a non-HOT UPDATE the backend will see the index entry
for the old row version and then check it, pointlessly. Since that has
just been modified, that won't ever be killed, so skipping the check
makes sense in those cases.
--
Simon Riggs http://www.EnterpriseDB.com/
