Re: Optimize LISTEN/NOTIFY - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Optimize LISTEN/NOTIFY
Date
Msg-id 2531672.1759868124@sss.pgh.pa.us
Whole thread Raw
In response to Re: Optimize LISTEN/NOTIFY  ("Joel Jacobson" <joel@compiler.org>)
List pgsql-hackers
"Joel Jacobson" <joel@compiler.org> writes:
> Ops, I see I got the list_member() code wrong. I've changed it to now
> create String nodes, and then use strVal().

Might be better to revert to the previous coding.  Using String
nodes is going to roughly double the space eaten for the list,
and it seems like it's not buying you a lot.

> I also changed back to dshash_find(..., false) in SignalBackends(),
> since that makes more sense to me, since we're not modifying entry.

Agreed.

I did a code coverage run and it seems like things are in pretty
good shape already.  async.c is about 88% covered and a lot of the
omissions are either Trace_notify or unreached error reports, which
I'm not especially concerned about.  The visible coverage gaps are:

1. asyncQueueFillWarning.  This wasn't covered before either, because
it doesn't seem very practical to exercise it in an everyday
regression test.  Since your patch doesn't touch that code nor the
queue contents, I'm not concerned here.

2. AtSubCommit_Notify's reparenting stanza.  This is a pre-existing
omission too, but maybe worth doing something about?

3. AtSubAbort_Notify's pendingActions cleanup loop; same comments.

4. notification_match is not called at all.  Again, pre-existing
coverage gap.

5. ChannelHashAddListener: "already registered" case is not reached,
which surprises me a bit, and neither is the "grow the array" stanza.
Since this is new code it might be worth adding coverage.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Paul Ramsey
Date:
Subject: Re: Add RESPECT/IGNORE NULLS and FROM FIRST/LAST options
Next
From: Peter Geoghegan
Date:
Subject: Re: Should we update the random_page_cost default value?