On Tue, 2002-05-28 at 13:57, Tom Lane wrote:
> Stephen Robert Norris <srn@commsecure.com.au> writes:
> > My reading of the code was that the signals didn't get delivered unless
> > the queue got too full, and that entries on the queue are created by the
> > vacuum (and other stuff) and processed when a backend does something,
> > thus the queue never gets too full.
>
> Good point. And certainly the async-notify code (which scans through
> pg_listener) is a lot more expensive than is needed just to respond to
> an SInval-queue-full condition; that looks to be a quick hack that was
> inserted without thought to performance. But I don't think we quite
> understand this issue yet. If your system can support 800 simultaneous
> useful queries then it shouldn't have a problem with 800 simultaneous
> scans of an empty pg_listener table.
>
> I'll ask again: is your system sized to support 800 *simultaneous*
> user queries? (One query per second on 800 connections is hardly
> the same thing.)
>
> regards, tom lane
I'm not sure; it can certainly do >1k queries/second through 800
simultaneous connections (about 1/connection second), but it's hard to
find enough machines to load it up that much...
One big difference, though, is that with the vacuum problem, the CPU
used is almost all (99%) system time; loading up the db with lots of
queries increases user time mostly, with little system time...
In any event, it seems a bug that merely having connections open causes
this problem! They aren't even in transactions...
Stephen