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

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: bharath(dot)rupireddyforpostgres(at)gmail(dot)com
Cc: andres(at)anarazel(dot)de, sawada(dot)mshk(at)gmail(dot)com, thomas(dot)munro(at)gmail(dot)com, bertranddrouvot(dot)pg(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org, pgsql(at)j-davis(dot)com, amit(dot)kapila16(at)gmail(dot)com, robertmhaas(at)gmail(dot)com
Subject: Re: walsender performance regression due to logical decoding on standby changes
Date: 2023-05-19 03:07:56
Message-ID: 20230519.120756.337226894962602552.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At Thu, 18 May 2023 20:11:11 +0530, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote in
> > > + ConditionVariableInit(&WalSndCtl->physicalWALSndCV);
> > > + ConditionVariableInit(&WalSndCtl->logicalWALSndCV);
> >
> > It's not obvious to me that it's worth having two CVs, because it's more
> > expensive to find no waiters in two CVs than to find no waiters in one CV.
>
> I disagree. In the tight per-WAL record recovery loop, WalSndWakeup
> wakes up logical walsenders for every WAL record, but it wakes up
> physical walsenders only if the applied WAL record causes a TLI
> switch. Therefore, the extra cost of spinlock acquire-release for per
> WAL record applies only for logical walsenders. On the other hand, if
> we were to use a single CV, we would be unnecessarily waking up (if at
> all they are sleeping) physical walsenders for every WAL record -
> which is costly IMO.

As I was reading this, I start thinking that one reason for the
regression could be to exccessive frequency of wakeups during logical
replication. In physical replication, we make sure to avoid exccessive
wakeups when the stream is tightly packed. I'm just wondering why
logical replication doesn't (or can't) do the same thing, IMHO.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2023-05-19 03:12:39 Re: PG 16 draft release notes ready
Previous Message jian he 2023-05-19 02:41:59 Re: PG 16 draft release notes ready