SUBTRANS: Minimizing calls to SubTransSetParent()

From: Simon Riggs <simon(dot)riggs(at)enterprisedb(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: SUBTRANS: Minimizing calls to SubTransSetParent()
Date: 2022-08-08 13:11:36
Message-ID: CANbhV-H8ov5+nCMBYQFKhO+UZJjrFgY_ORiMWr3RhS4+x44PzA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 4 Aug 2022 at 13:11, Simon Riggs <simon(dot)riggs(at)enterprisedb(dot)com> wrote:
>
> On Wed, 3 Aug 2022 at 20:18, Andres Freund <andres(at)anarazel(dot)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.

This might then make viable a simple rewrite of SUBTRANS using a hash
table, as proposed by Andres. But in any case, it will allow us to
design a densely packed SUBTRANS replacement that does not generate as
much contention and I/O.

NOTE that this patchset does not touch SUBTRANS at all, it just
minimizes the calls in preparation for a later redesign in a later
patch. If this patch/later versions of it is committed in Sept CF,
then we should be in good shape to post a subtrans redesign patch by
major patch deadline at end of year.

Patches 001 and 002 are common elements of a different patch,
"Smoothing the subtrans performance catastrophe", but other than that,
the two patches are otherwise independent of each other.

Where does this come from? I learnt a lot about subxids when coding
Hot Standby, specifically commit 06da3c570f21394003. This patch just
builds upon that earlier understanding.

Comments please.

--
Simon Riggs http://www.EnterpriseDB.com/

Attachment Content-Type Size
003_minimize_calls_to_SubTransSetParent.v7.patch application/octet-stream 9.8 KB
002_new_isolation_tests_for_subxids.v2.patch application/octet-stream 2.3 KB
001_subx_include_subxids_even_if_overflowed.v2.patch application/octet-stream 3.8 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bharath Rupireddy 2022-08-08 13:43:25 Re: An attempt to avoid locally-committed-but-not-replicated-to-standby-transactions in synchronous replication
Previous Message Yedil Serzhan 2022-08-08 12:50:17 Asking for feedback on Pgperffarm