Re: LISTEN / NOTIFY performance in 8.3

Joel Stevenson <joelstevenson@mac.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.00usec 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