From: Joel Stevenson <joelstevenson@mac.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-performance@postgresql.org
Subject: Re: LISTEN / NOTIFY performance in 8.3
Date: Tue, 26 Feb 2008 08:26:30 -0800
Message-ID: <p06240812c3e9ea5ea7f8@[10.0.1.253]> (raw)
In-Reply-To: <6730.1203829093@sss.pgh.pa.us>
References: <p06240804c3e61871f289@[10.0.1.253]>
<5576.1203795335@sss.pgh.pa.us>
<p06240806c3e67e31cbd0@[10.0.1.253]>
<6730.1203829093@sss.pgh.pa.us>
At 11:58 PM -0500 2/23/08, Tom Lane wrote:
> > Attached is a perl script that sort of simulates what's going on.
>
>Thanks for the script. It's not showing any particular problems here,
>though. With log_min_duration_statement = 10, the only statements that
>(slightly) exceed 10ms are the select count(*) from generate_series(1,
>15000) ones.
I tried the test script on another machine (similar but not identical
to the original machine) running 8.3 and although the notify
performance was *much* better than the original I still see
notifications taking longer than the select count(*) from
generate_series(1, 15000) queries, and also longer than some simple
updates to other tables that are also happening on the server.
duration: 10.030 ms statement: select count(*) from generate_series(1, 15000)
duration: 224.833 ms statement: NOTIFY to_producer
Perhaps this shouldn't be made much of as I'm sure there are many way
that this could quite naturally happen.
I've been thinking of LISTEN / NOTIFY as one of the least expensive
and therefore speedy ways to get the word out to participating
processes that something has changed (versus using a manually setup
signals table that interested parties updated and selected from).
Now that I see a little bit more of what goes on under the hood of
this function I see that it's still basically table-driven and I'll
adjust my expectations accordingly, but I'm still puzzled by the
hugely slow notifications showing up on the original server running
the producer / consumer setup.
With ps I can see some postgres backends with a 'notify interrupt
waiting' command line during the tests - could it be an issue with
signal handling on the original machine - something entirely outside
of PG's control?
Thx,
-Joel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: joelstevenson@mac.com, tgl@sss.pgh.pa.us
Subject: Re: LISTEN / NOTIFY performance in 8.3
In-Reply-To: <p06240812c3e9ea5ea7f8@[10.0.1.253]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox