Hi
As Pg doesn't presently support client push for notifications arising
from LISTEN/NOTIFY, I'm wondering if anybody here has done any research
into the cheapest statement to issue to check for such notifications.
First: is it worth caring? Or is a `SELECT 1;' every few seconds from a
small (50-ish) number of clients unlikely to have a detectable effect on
load?
Does it have any significant costs (considering that each statement
starts its own transaction) ? Is it worth issuing:
BEGIN ISOLATION LEVEL READ COMMITTED, READ ONLY; SELECT 1; ROLLBACK;
rather than just `SELECT 1' ?
I'll be doing some testing on all of this, of course, but I thought I'd
ask in case others have looked into this already. I didn't see anything
much in the archives.
One thing I've noticed is that an invalid statement that fails to parse
still produces the notifications, though it avoids planning and query
execution. However, it'll also fill the error log with garbage, so it's
not exactly desirable. The error paths are probably more expensive than
just running the SELECT anyway.
I wonder if it'd be useful to have a utility statement (perhaps 'LISTEN'
without arguments?) that was essentially a no-op that _only_ checked
notifications. It'd make it easier to see why clients were issuing
apparently random statements, and could possibly be also excluded from
statement logging even when other things were logged. Would there be any
support for the idea of something like that? It might be project #2 for
me once I get around to posting the array_reverse function, if so.
Also: Is there any practical way Pg can ever support server-to-client
push for notifications? I assume the reasons why it doesn't at present
are to do with the protocol and with deadlock/concurrency issues at the
wire level ... is that so?
--
Craig Ringer
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
