On Mon, Aug 8, 2022 at 6:41 PM Simon Riggs <simon.ri...@enterprisedb.com> wrote: > > On Thu, 4 Aug 2022 at 13:11, Simon Riggs <simon.ri...@enterprisedb.com> wrote: > > > > On Wed, 3 Aug 2022 at 20:18, Andres Freund <and...@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
