From: James Mansion <james@mansionfamily.plus.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Joel Stevenson <joelstevenson@mac.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: LISTEN / NOTIFY performance in 8.3
Date: Wed, 27 Feb 2008 06:00:05 +0000
Message-ID: <47C4FC65.6050302@mansionfamily.plus.com> (raw)
In-Reply-To: <9940.1204068830@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>
<p06240812c3e9ea5ea7f8@[10.0.1.253]>
<5080.1204047806@sss.pgh.pa.us>
<47C48F9E.7000505@mansionfamily.plus.com>
<9940.1204068830@sss.pgh.pa.us>
Tom Lane wrote:
> Hardly --- how's that going to pass a notify name? Also, a lot of
> people want some payload data in a notify, not just a condition name;
> any reimplementation that doesn't address that desire probably won't
> get accepted.
>
Ah - forgot about the name. At least there need be just one instance of
a name record queued
per worker if I'm reading the documentation right - it suggest that
notifications can be folded
with the proviso that if the process generates a notification and at
least one other process
generates a notification then it will get at least (but possibly only)
two events. Not sure why
the PID is there rather than a couple of flag bits.
You'll alsways have the danger of overflowing a shm area and need to
spill: is the signal and then
lookup in storage materially quicker than using the master process to
route messages via pipes?
As you say, you have a lock contention issue and often the total signal
data volume outstanding
for a single back end will be less than will fit in a kernel's pipe buffer.
The sending processes can track what signals they've generated in the
current transaction so
the master (or signal distributor) needn't get bombarded with signals
from lots of rows within
one transaction.
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: james@mansionfamily.plus.com, tgl@sss.pgh.pa.us, joelstevenson@mac.com
Subject: Re: LISTEN / NOTIFY performance in 8.3
In-Reply-To: <47C4FC65.6050302@mansionfamily.plus.com>
* 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