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

Hi,

On 2023-05-10 08:39:08 +0200, Drouvot, Bertrand wrote:
> On 5/9/23 11:00 PM, Andres Freund wrote:
> > Hi,
> >
> > On 2023-05-09 13:38:24 -0700, Jeff Davis wrote:
> > > On Tue, 2023-05-09 at 12:02 -0700, Andres Freund wrote:
> > > > I don't think the approach of not having any sort of "registry" of
> > > > whether
> > > > anybody is waiting for the replay position to be updated is
> > > > feasible. Iterating over all walsenders slots is just too expensive -
> > >
> > > Would it work to use a shared counter for the waiters (or, two
> > > counters, one for physical and one for logical), and just early exit if
> > > the count is zero?
> >
> > That doesn't really fix the problem - once you have a single walsender
> > connected, performance is bad again.
> >
>
> Just to clarify, do you mean that if there is only one remaining active walsender that, say,
> has been located at slot n, then we’d still have to loop from 0 to n in WalSndWakeup()?

I understood Jeff's proposal to just have an early exit if there are no
walsenders connected at all. But yes, even if we stopped iterating after
finding the number of slots we needed to, having to iterate over empty slots
would be an issue.

But TBH, even if we only did work for connected walsenders, I think this would
still be a performance issue. Acquiring O(#connected-walsenders) spinlocks for
every record is just too expensive.

Greetings,

Andres Freund