Re: suboverflowed subtransactions concurrency performance optimize - Mailing list pgsql-hackers

From Andres Freund
Subject Re: suboverflowed subtransactions concurrency performance optimize
Date
Msg-id 20220527155502.gpja3roizggvbgeh@alap3.anarazel.de
Whole thread Raw
In response to Re: suboverflowed subtransactions concurrency performance optimize  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: suboverflowed subtransactions concurrency performance optimize  (Peter Geoghegan <pg@bowt.ie>)
Re: suboverflowed subtransactions concurrency performance optimize  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
Hi,

On 2022-05-27 15:44:39 +0530, Amit Kapila wrote:
> On Thu, May 26, 2022 at 12:53 PM Michael Paquier <michael@paquier.xyz> wrote:
> >
> > On Tue, May 24, 2022 at 04:52:50PM -0700, Andres Freund wrote:
> >
> > > 2) xid wraparound. There's nothing forcing SubTransGetTopmostTransaction() to
> > >    be called regularly, so even if a backend isn't idle, the cache could just
> > >    get more and more outdated until hitting wraparound
> >
> > Hence, you mean that the non-regularity of the call makes it more
> > exposed to an inconsistent result after a wraparound?
> >
> 
> Won't in theory the similar cache in transam.c is also prone to
> similar behavior?

It's not quite the same risk, because there we are likely to actually hit the
cache regularly. Whereas quite normal workloads might not hit this cache for
days on end.


> 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.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: PG15 beta1 sort performance regression due to Generation context change
Next
From: Greg Hennessy
Date:
Subject: Re: selectivity function