Re: walsender performance regression due to logical decoding on standby changes

Thomas Munro <thomas.munro@gmail.com>

From: Thomas Munro <thomas.munro@gmail.com>
To: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Cc: "Drouvot, Bertrand" <bertranddrouvot.pg@gmail.com>, Andres Freund <andres@anarazel.de>, pgsql-hackers@postgresql.org, Jeff Davis <pgsql@j-davis.com>, Amit Kapila <amit.kapila16@gmail.com>, Robert Haas <robertmhaas@gmail.com>, Masahiko Sawada <sawada.mshk@gmail.com>
Date: 2023-05-15T04:48:51Z
Lists: pgsql-hackers
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.



Commits

  1. Optimize walsender wake up logic using condition variables

  2. For cascading replication, wake physical and logical walsenders separately