On Mon, Aug 8, 2022 at 6:41 PM Simon Riggs <simon.riggs@enterprisedb.com> wrote:
>
> On Thu, 4 Aug 2022 at 13:11, Simon Riggs <simon.riggs@enterprisedb.com> wrote:
> >
> > On Wed, 3 Aug 2022 at 20:18, Andres Freund <andres@anarazel.de> wrote:
> >
> > > I think we should consider redesigning subtrans more substantially - even with
> > > the changes you propose here, there's still plenty ways to hit really bad
> > > performance. And there's only so much we can do about that without more
> > > fundamental design changes.
> >
> > I completely agree - you will be glad to hear that I've been working
> > on a redesign of the subtrans module.
> ...
> > I will post my patch, when complete, in a different thread.
>
> The attached patch reduces the overhead of SUBTRANS by minimizing the
> number of times SubTransSetParent() is called, to below 1% of the
> current rate in common cases.
>
> Instead of blindly calling SubTransSetParent() for every subxid, this
> proposal only calls SubTransSetParent() when that information will be
> required for later use. It does this by analyzing all of the callers
> of SubTransGetParent() and uses these pre-conditions to filter out
> calls/subxids that will never be required, for various reasons. It
> redesigns the way XactLockTableWait() calls
> SubTransGetTopmostTransactionId() to allow this.
>
> This short patchset compiles and passes make check-world, with lengthy comments.
Does this patch set work independently or it has dependency on the
patches on the other thread "Smoothing the subtrans performance
catastrophe"? Because in this patch I see no code where we are
changing anything to control the access of SubTransGetParent() from
SubTransGetTopmostTransactionId()?
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
