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

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-10 22:18:58
Message-ID: 22204.1568153938@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:
> 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2019-09-10 22:28:12 Re: Multivariate MCV list vs. statistics target
Previous Message Nikita Glukhov 2019-09-10 22:15:11 Re: [PATCH] Opclass parameters