Received: from localhost (unknown [200.46.204.184])
	by postgresql.org (Postfix) with ESMTP id 70D4F2E0051
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Wed, 27 Feb 2008 01:56:47 -0400 (AST)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024)
	with ESMTP id 17793-08-2
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Wed, 27 Feb 2008 01:56:42 -0400 (AST)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.5
Received: from ptb-relay01.plus.net (ptb-relay01.plus.net [212.159.14.212])
	by postgresql.org (Postfix) with ESMTP id 2F17B2E0070
	for <pgsql-performance@postgresql.org>;
	Wed, 27 Feb 2008 01:56:42 -0400 (AST)
Received: from [80.229.150.39] (helo=mansionfamily.plus.com)
	by ptb-relay01.plus.net with esmtp (Exim) id 1JUFHU-0005wO-Bu
	for pgsql-performance@postgresql.org; Wed, 27 Feb 2008 05:56:40 +0000
Received: from [192.168.0.87] ([192.168.0.87]:1470)
	by mansionfamily.plus.com with [XMail 1.22 ESMTP Server]
	id <S120C9> for <pgsql-performance@postgresql.org> from
	<james@mansionfamily.plus.com>; Wed, 27 Feb 2008 06:00:49 -0000
Message-ID: <47C4FC65.6050302@mansionfamily.plus.com>
Date: Wed, 27 Feb 2008 06:00:05 +0000
From: James Mansion <james@mansionfamily.plus.com>
Organization: MsgWare
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Joel Stevenson <joelstevenson@mac.com>, pgsql-performance@postgresql.org
Subject: Re: LISTEN / NOTIFY performance in 8.3
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>
In-Reply-To: <9940.1204068830@sss.pgh.pa.us>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Plusnet-Relay: b9f0614fc24f89e1eb30bdec8a7b8c61
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200802/366
X-Sequence-Number: 28908

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.