From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Martijn van Oosterhout <kleptog(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [PATCH] Improve performance of NOTIFY over many databases (v2) |
Date: | 2019-09-16 13:33:35 |
Message-ID: | 28365.1568640815@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Martijn van Oosterhout <kleptog(at)gmail(dot)com> writes:
> On Mon, 16 Sep 2019 at 00:14, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2019-09-16 13:40:56 | Re: [HACKERS] [PATCH] pageinspect function to decode infomasks |
Previous Message | Robert Haas | 2019-09-16 13:30:06 | Re: block-level incremental backup |