From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Joel Stevenson <joelstevenson(at)mac(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: LISTEN / NOTIFY performance in 8.3 |
Date: | 2008-02-25 19:57:58 |
Message-ID: | 1909.1203969478@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Joel Stevenson <joelstevenson(at)mac(dot)com> writes:
> I turned on all autovacuum logging and cranked up the test script and
> have it fork 25 consumers each running 25 iterations. At that level
> on my machine I can get the lock waiting to exceed the 1s
> deadlock_timeout right away but the autovacuum activity on
> pg_listener is entirely absent until the end when the forked
> consumers are mostly done and disconnected.
Hmph. At 25/100 I can get a few complaints about NOTIFY taking more
than 20ms, but it seems to be due to blocking behind autovacuum, as
in this example:
2008-02-25 14:53:41.812 EST 13773 LOG: automatic vacuum of table "joels.pg_catalog.pg_listener": index scans: 0
pages: 0 removed, 78 remain
tuples: 5560 removed, 25 remain
system usage: CPU 0.00s/0.00u sec elapsed 0.00 sec
2008-02-25 14:53:41.850 EST 13773 LOG: automatic analyze of table "joels.pg_catalog.pg_listener" system usage: CPU 0.00s/0.00u sec elapsed 0.03 sec
2008-02-25 14:53:41.851 EST 13728 LOG: duration: 29.270 ms statement: NOTIFY to_producer
2008-02-25 14:53:41.852 EST 13758 LOG: duration: 22.835 ms statement: NOTIFY to_producer
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?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Joel Stevenson | 2008-02-25 20:37:24 | Re: LISTEN / NOTIFY performance in 8.3 |
Previous Message | Joel Stevenson | 2008-02-25 19:15:44 | Re: LISTEN / NOTIFY performance in 8.3 |