Re: walsender performance regression due to logical decoding on standby changes - Mailing list pgsql-hackers

From Bharath Rupireddy
Subject Re: walsender performance regression due to logical decoding on standby changes
Date
Msg-id CALj2ACWeo64RSqf8tDbnSSUm_vbpK5GYdDiiFQk8E3Fg38mBdw@mail.gmail.com
Whole thread Raw
In response to Re: walsender performance regression due to logical decoding on standby changes  (Masahiko Sawada <sawada.mshk@gmail.com>)
Responses Re: walsender performance regression due to logical decoding on standby changes
Re: walsender performance regression due to logical decoding on standby changes
List pgsql-hackers
On Mon, May 15, 2023 at 6:14 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>
> On Mon, May 15, 2023 at 1:49 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> >
> > On Fri, May 12, 2023 at 11:58 PM Bharath Rupireddy
> > <bharath.rupireddyforpostgres@gmail.com> wrote:
> > > Andres, rightly put it - 'mis-using' CV infrastructure. It is simple,
> > > works, and makes the WalSndWakeup() easy solving the performance
> > > regression.
> >
> > Yeah, this seems OK, and better than the complicated alternatives.  If
> > one day we want to implement CVs some other way so that this
> > I-know-that-CVs-are-really-made-out-of-latches abstraction leak
> > becomes a problem, and we still need this, well then we can make a
> > separate latch-wait-list thing.
>
> +1

Thanks for acknowledging the approach.

On Mon, May 15, 2023 at 2:11 PM Drouvot, Bertrand
<bertranddrouvot.pg@gmail.com> wrote:
>
> Thanks for V2! It does look good to me and I like the fact that
> WalSndWakeup() does not need to loop on all the Walsenders slot
> anymore (for both the physical and logical cases).

Indeed, it doesn't have to.

On Mon, May 15, 2023 at 7:50 AM Zhijie Hou (Fujitsu)
<houzj.fnst@fujitsu.com> wrote:
>
> Thanks for updating the patch. I did some simple primary->standby replication test for the
> patch and can see the degradation doesn't happen in the replication after applying it[1].
>
> One nitpick in the comment:
>
> +        * walsenders. It makes WalSndWakeup() callers life easy.
>
> callers life easy => callers' life easy.

Changed.

> [1]
> max_wal_senders = 100
> before regression(ms)                after regression(ms)    v2 patch(ms)
> 13394.4013                          14141.2615              13455.2543
> Compared with before regression     5.58%                   0.45%
>
> max_wal_senders = 200
> before regression(ms)                after regression(ms)     v2 patch(ms)
> 13280.8507                          14597.1173              13632.0606
> Compared with before regression     9.91%                   1.64%
>
> max_wal_senders = 300
> before regression(ms)                after regression(ms)     v2 patch(ms)
> 13535.0232                          16735.7379              13705.7135
> Compared with before regression     23.65%                  1.26%

Yes, the numbers with v2 patch look close to where we were before.
Thanks for confirming. Just wondering, where does this extra
0.45%/1.64%/1.26% coming from?

Please find the attached v3 with the review comment addressed.

Do we need to add an open item for this issue in
https://wiki.postgresql.org/wiki/PostgreSQL_16_Open_Items? If yes, can
anyone in this loop add one?

--
Bharath Rupireddy
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: psql: Could we get "-- " prefixing on the **** QUERY **** outputs? (ECHO_HIDDEN)
Next
From: Marina Polyakova
Date:
Subject: Conflict between regression tests namespace & transactions due to recent changes