Feedback-ID: id4a34324:Fastmail
Date: Fri, 27 May 2022 08:55:02 -0700
From: Andres Freund <andres@anarazel.de>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: 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>
Subject: Re: suboverflowed subtransactions concurrency performance optimize
Message-ID: <20220527155502.gpja3roizggvbgeh@alap3.anarazel.de>
References: <EE4E9BF3-A824-4940-B13F-7448B43DA500@yandex-team.ru>
 <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>
 <Yk54Y+c6gXfBnaiK@paquier.xyz>
 <20220524235250.gtt3uu5zktfkr4hv@alap3.anarazel.de>
 <Yo8q4r+3GAAgm5kd@paquier.xyz>
 <CAA4eK1L7ou9=EJYBDsrzqeCw2dO_RLUMjsMFxJAESc5tyb_S1A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CAA4eK1L7ou9=EJYBDsrzqeCw2dO_RLUMjsMFxJAESc5tyb_S1A@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/20220527155502.gpja3roizggvbgeh%40alap3.anarazel.de>
Precedence: bulk

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