Skip site navigation (1) Skip section navigation (2)

Re: LISTEN / NOTIFY performance in 8.3

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Joel Stevenson <joelstevenson(at)mac(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: LISTEN / NOTIFY performance in 8.3
Date: 2008-02-26 23:01:58
Message-ID: 9501.1204066918@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-performance
Joel Stevenson <joelstevenson(at)mac(dot)com> writes:
> What's really baffling is that there are plenty of other OLTP queries 
> going in multiple backends simultaneously that don't fall over my 
> 300ms query log threshold, and yet NOTIFY and LISTEN consistently do. 
> What's more it's looks like it's only happening for registered 
> listener relnames.

Hmm, that says that it's not a matter of locking on pg_listener,
but of actually applying the row update(s) and/or signaling the
recipient(s).  If you're not seeing performance issues for ordinary
table-update operations it's hard to see why pg_listener updates would
be any worse, so that seems to point the finger at the signaling.
Which is just a matter of a kill(2) and shouldn't be that expensive.

It might be interesting to try strace'ing the whole PG process tree
while these notifies are going on, and seeing if you can identify
any specific kernel calls that seem to take a long time.

			regards, tom lane

In response to

Responses

pgsql-performance by date

Next:From: Tom LaneDate: 2008-02-26 23:33:50
Subject: Re: LISTEN / NOTIFY performance in 8.3
Previous:From: Joshua D. DrakeDate: 2008-02-26 22:37:38
Subject: Re: disabling an index without deleting it?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group