Re: [PATCH] Improve performance of NOTIFY over many databases (v2) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PATCH] Improve performance of NOTIFY over many databases (v2)
Date
Msg-id 28365.1568640815@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PATCH] Improve performance of NOTIFY over many databases (v2)  (Martijn van Oosterhout <kleptog@gmail.com>)
Responses Re: [PATCH] Improve performance of NOTIFY over many databases (v2)
List pgsql-hackers
Martijn van Oosterhout <kleptog@gmail.com> writes:
> On Mon, 16 Sep 2019 at 00:14, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> ... I also think we
>> can simplify the handling of other-database listeners by including
>> them in the set signaled by SignalBackends, but only if they're
>> several pages behind.  So that leads me to the attached patch;
>> what do you think?

> I think I like the idea of having SignalBackend do the waking up a
> slow backend but I'm not enthused by the "lets wake up (at once)
> everyone that is behind". That's one of the issues I was explicitly
> trying to solve. If there are any significant number of "slow"
> backends then we get the "thundering herd" again.

But do we care?  With asyncQueueAdvanceTail gone from the listeners,
there's no longer an exclusive lock for them to contend on.  And,
again, I failed to see any significant contention even in HEAD as it
stands; so I'm unconvinced that you're solving a live problem.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: block-level incremental backup
Next
From: Michael Paquier
Date:
Subject: Re: [HACKERS] [PATCH] pageinspect function to decode infomasks