Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 4A1E22E020E for ; Mon, 25 Feb 2008 16:07:10 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 33150-01-6 for ; Mon, 25 Feb 2008 16:07:07 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id 399D12E0378 for ; Mon, 25 Feb 2008 15:58:01 -0400 (AST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id m1PJvwli001910; Mon, 25 Feb 2008 14:57:58 -0500 (EST) To: Joel Stevenson cc: pgsql-performance@postgresql.org Subject: Re: LISTEN / NOTIFY performance in 8.3 In-reply-to: References: <29568.1203963194@sss.pgh.pa.us> Comments: In-reply-to Joel Stevenson message dated "Mon, 25 Feb 2008 11:15:44 -0800" Date: Mon, 25 Feb 2008 14:57:58 -0500 Message-ID: <1909.1203969478@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200802/329 X-Sequence-Number: 28871 Joel Stevenson 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