From: | Joel Stevenson <jrs_1(at)mac(dot)com> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: LISTEN / NOTIFY performance in 8.3 |
Date: | 2008-02-25 16:48:20 |
Message-ID: | p06240807c3e8a18faa42@[192.168.0.9] |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
>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
database 16387 after 992.397 ms
...
process 22791 acquired ExclusiveLock on relation 2614 of database
16387 after 1433.152 ms
deadlock_timeout is left at the default 1s setting.
Though these are being generated during application activity -
running the simulation script does produce 300ms - 600ms NOTIFY
statements but doesn't (at the moment) trigger a lock_wait log entry.
From | Date | Subject | |
---|---|---|---|
Next Message | Kynn Jones | 2008-02-25 16:50:44 | Re: Q on views and performance |
Previous Message | Matthew | 2008-02-25 14:27:12 | Re: Weird issue with planner choosing seq scan |