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 22204.1568153938@sss.pgh.pa.us
Whole thread Raw
In response to [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:
> The original three patches have been collapsed into one as given the
> changes discussed it didn't make sense to keep them separate. There
> are now two patches (the third is just to help with testing):

> Patch 1: Tracks the listening backends in a list so non-listening
> backends can be quickly skipped over. This is separate because it's
> orthogonal to the rest of the changes and there are other ways to do
> this.

> Patch 2: This is the meat of the change. It implements all the
> suggestions discussed:

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.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Nikita Glukhov
Date:
Subject: Re: [PATCH] Opclass parameters
Next
From: Tomas Vondra
Date:
Subject: Re: Multivariate MCV list vs. statistics target