public inbox for [email protected]
help / color / mirror / Atom feedFrom: Andres Freund <[email protected]>
To: Amit Kapila <[email protected]>
Cc: Michael Paquier <[email protected]>
Cc: Julien Rouhaud <[email protected]>
Cc: Simon Riggs <[email protected]>
Cc: Andrey Borodin <[email protected]>
Cc: Pengchengliu <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: suboverflowed subtransactions concurrency performance optimize
Date: Fri, 27 May 2022 08:55:02 -0700
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAA4eK1L7ou9=EJYBDsrzqeCw2dO_RLUMjsMFxJAESc5tyb_S1A@mail.gmail.com>
References: <[email protected]>
<CANbhV-GdpdpkvgAaRgaLsKQjTOdoGDXpCJkKU7wLrUBthTC_qQ@mail.gmail.com>
<CANbhV-G8Co=yq4v4BkW7MJDqVt68K_8A48nAZ_+8UQS7LrwLEQ@mail.gmail.com>
<20220307094855.kkc6vagshyc6xsbn@jrouhaud>
<CANbhV-E9eFXNuN-NMnH5xjRDGAM+Vi8+CUi5c3cXgeo93NM9Aw@mail.gmail.com>
<20220307141741.6jidhra3tup6uiaf@jrouhaud>
<[email protected]>
<[email protected]>
<[email protected]>
<CAA4eK1L7ou9=EJYBDsrzqeCw2dO_RLUMjsMFxJAESc5tyb_S1A@mail.gmail.com>
Hi,
On 2022-05-27 15:44:39 +0530, Amit Kapila wrote:
> On Thu, May 26, 2022 at 12:53 PM Michael Paquier <[email protected]> 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
view thread (30+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: suboverflowed subtransactions concurrency performance optimize
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox