At 6:01 PM -0500 2/26/08, Tom Lane wrote:
Hmm, that says that it's not a matter of locking on pg_listener,
but of actually applying the row update(s) and/or signaling the
recipient(s). If you're not seeing performance issues for ordinary
table-update operations it's hard to see why pg_listener u
At 12:43 PM -0500 2/26/08, Tom Lane wrote:
I'm still baffled by why we aren't seeing comparable performance for the
same test case. What I'm testing on is couple-year-old desktop kit
(dual 2.8GHz Xeon, consumer-grade disk drive) --- I had assumed your
server would be at least as fast as that, bu
At 11:58 PM -0500 2/23/08, Tom Lane wrote:
> Attached is a perl script that sort of simulates what's going on.
Thanks for the script. It's not showing any particular problems here,
though. With log_min_duration_statement = 10, the only statements that
(slightly) exceed 10ms are the select cou
At 2:57 PM -0500 2/25/08, Tom Lane wrote:
It's weird that the behavior is robust for you but I can't make it
happen at all. Would you show the output of pg_config, as well as
all your nondefault postgresql.conf settings?
pg_config:
BINDIR = /usr/local/pgsql/bin
DOCDIR = /usr/local/pgsql/doc
IN
At 1:13 PM -0500 2/25/08, Tom Lane wrote:
Joel Stevenson <[EMAIL PROTECTED]> writes:
Also, it might be worth enabling log_lock_waits to see if the slow
notifies are due to having to wait on some lock or other.
Turning on log_lock_waits shows that there is a lot of waiting for
lo
Also, it might be worth enabling log_lock_waits to see if the slow
notifies are due to having to wait on some lock or other.
Turning on log_lock_waits shows that there is a lot of waiting for
locks on the pg_listener table ala:
process 22791 still waiting for ExclusiveLock on relation 2614 of
Also, it might be worth enabling log_lock_waits to see if the slow
notifies are due to having to wait on some lock or other.
Turning on log_lock_waits shows that there is a lot of waiting for
locks on the pg_listener table ala:
process 22791 still waiting for ExclusiveLock on relation 2614 of
At 1:57 PM -0500 2/24/08, Tom Lane wrote:
Joel Stevenson <[EMAIL PROTECTED]> writes:
This sounds a bit like pg_listener has gotten bloated. Try a "VACUUM
VERBOSE pg_listener" (as superuser) and see what it says.
At the moment (server is inactive):
pcdb=# VACUUM VER
At 11:58 PM -0500 2/23/08, Tom Lane wrote:
Joel Stevenson <[EMAIL PROTECTED]> writes:
That's strange, I would not have thought that listen/notify behavior
would change at all. How are you measuring this delay exactly?
Can you put together a self-contained test case?
Attache
Hi,
I'm noticing a strange increase in the amount of time it takes to
issue a NOTIFY statement.
I have an existing app that provides a producer / consumer type of
queue and that uses the LISTEN / NOTIFY mechanism to signal the
consumers of new items arriving in the queue. The consumers then
10 matches
Mail list logo
