Horton

Re: suboverflowed subtransactions concurrency performance optimize

Peter Geoghegan <pg@bowt.ie>

View thread View on postgr.es
From: Peter Geoghegan <pg@bowt.ie>
To: Andres Freund <andres@anarazel.de>
Cc: Amit Kapila <amit.kapila16@gmail.com>, Michael Paquier <michael@paquier.xyz>, Julien Rouhaud <rjuju123@gmail.com>, Simon Riggs <simon.riggs@enterprisedb.com>, Andrey Borodin <x4mmm@yandex-team.ru>, Pengchengliu <pengchengliu@tju.edu.cn>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2022-05-27T18:48:45Z
Lists: pgsql-hackers 
On Fri, May 27, 2022 at 8:55 AM Andres Freund <andres@anarazel.de> wrote:
> > Anyway, how about if we clear this cache for subtrans whenever
> > TransactionXmin is advanced and cachedFetchSubXid precedes it? The
> > comments atop SubTransGetTopmostTransaction seem to state that we
> > don't care about the exact topmost parent when the intermediate one
> > precedes TransactionXmin. I think it should preserve the optimization
> > because anyway for such cases there is a fast path in
> > SubTransGetTopmostTransaction.
>
> There's not even a proof this does speed up anything useful! There's not a
> single benchmark for the patch.

I find it hard to believe that there wasn't even a cursory effort at
performance validation before this was committed, but that's what it
looks like.

-- 
Peter Geoghegan

Commits

  1. Revert "Add single-item cache when looking at topmost XID of a subtrans XID"

  2. Add single-item cache when looking at topmost XID of a subtrans XID

  3. Fix handling of partitioned index in RelationGetNumberOfBlocksInFork()