To: Joel Stevenson <joelstevenson@mac.com>
cc: pgsql-performance@postgresql.org
Subject: Re: LISTEN / NOTIFY performance in 8.3 
In-reply-to: <p06240808c3e6ad2bce2f@[10.0.1.253]> 
References: <p06240804c3e61871f289@[10.0.1.253]>
	<5576.1203795335@sss.pgh.pa.us>
	<p06240806c3e67e31cbd0@[10.0.1.253]>
	<6730.1203829093@sss.pgh.pa.us>
	<p06240808c3e6ad2bce2f@[10.0.1.253]>
Comments: In-reply-to Joel Stevenson <joelstevenson@mac.com>
	message dated "Sat, 23 Feb 2008 21:22:29 -0800"
Date: Sun, 24 Feb 2008 13:57:48 -0500
Message-ID: <6092.1203879468@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Joel Stevenson <joelstevenson@mac.com> 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 VERBOSE pg_listener;
> INFO:  vacuuming "pg_catalog.pg_listener"
> INFO:  "pg_listener": removed 1 row versions in 1 pages
> INFO:  "pg_listener": found 1 removable, 21 nonremovable row versions 
> in 28 pages

OK, that destroys the table-bloat theory.  Just to make sure, I
pre-populated pg_listener with enough dead rows to make 28 pages,
but I still don't see any slow notifies or noticeable load in vmstat.

That server is not quite "inactive", though.  What are the 21 remaining
pg_listener entries for?  Is it possible that those jobs are having
some impact on the ones run by the test script?

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.

			regards, tom lane