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

Re: NOTIFY performance

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Artur Zając <azajac(at)ang(dot)com(dot)pl>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: NOTIFY performance
Date: 2012-08-31 19:54:26
Message-ID: CAMkU=1x-6Q2gG6muiUWHzoUkYMQePS52hds6D=VjF3RvxppT5g@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-performance
On Fri, Aug 24, 2012 at 11:46 AM, Artur Zając <azajac(at)ang(dot)com(dot)pl> wrote:
> Hello,
>
>
> I would like to create some application using triggers and LISTEN/NOTIFY
> framework. I've tested it, and I noticed that performance of NOTIFY
> significally decreases with increasing number of distinct NOTIFIES in
> transaction.
> I found that function AsyncExistsPendingNotify is responsibe for it. I think
> that complexivity of searching duplicates there is O(N^2). Would be possible
> to improve performance of it? Maybe by using list for elements precedence
> and binary search tree for searching duplicates - with complexivity of
> O(Nlog2(N)).

I wonder if should be trying to drop duplicates at all.  I think that
doing that made a lot more sense before payloads existed.

The docs said that the system "can" drop duplicates, so making it no
longer do so would be backwards compatible.

Maybe drop duplicates where the payload was the empty string, but keep
them otherwise?

Cheers,

Jeff


In response to

Responses

pgsql-performance by date

Next:From: Tom LaneDate: 2012-08-31 20:22:59
Subject: Re: NOTIFY performance
Previous:From: Jeff JanesDate: 2012-08-31 16:17:19
Subject: Re: exponential performance decrease in ISD transaction

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