Re: [PATCH] Improve performance of NOTIFY over many databases (v2)

Martijn van Oosterhout <kleptog@gmail.com>

From: Martijn van Oosterhout <kleptog@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org
Date: 2019-09-11T14:07:17Z
Lists: pgsql-hackers

Attachments

Hoi Tom,


On Wed, 11 Sep 2019 at 00:18, Tom Lane <tgl@sss.pgh.pa.us> wrote:

>
> I pushed 0001 after doing some hacking on it --- it was sloppy about
> datatypes, and about whether the invalid-entry value is 0 or -1,
> and it was just wrong about keeping the list in backendid order.
> (You can't conditionally skip looking for where to put the new
> entry, if you want to maintain the order.  I thought about just
> defining the list as unordered, which would simplify joining the
> list initially, but that could get pretty cache-unfriendly when
> there are lots of entries.)
>
> 0002 is now going to need a rebase, so please do that.
>
>
Thanks for this, and good catch. Looks like I didn't test the first patch
by itself very well.

Here is the rebased second patch.

Thanks in advance,
-- 
Martijn van Oosterhout <kleptog@gmail.com> http://svana.org/kleptog/

Commits

  1. Make some efficiency improvements in LISTEN/NOTIFY.

  2. Reduce overhead of scanning the backend[] array in LISTEN/NOTIFY.