Re: Performance of the listen command - Mailing list pgsql-general

From Alvaro Herrera
Subject Re: Performance of the listen command
Date
Msg-id 20060730164833.GB5906@surnet.cl
Whole thread Raw
In response to Re: Performance of the listen command  (Flemming Frandsen <ff@partyticket.net>)
List pgsql-general
Flemming Frandsen wrote:
> Christopher Browne wrote:
> >There's a demerit:
> >c) If there are a LOT of events, that might not fit in memory nicely.
>
> If you have that many events then the current implementation is going to
> suck hard as well:)

The difference is that the current implementation *works* regardless of
the number of active listeners.  With the in-memory idea, you might have
to drop some listeners in order to make them fit in memory, which makes
that a non-starter, unless you find a solution to shave some stuff to
disk.  That's where the efficiency argument kicks in.

This is a bit worse than it sounds because the memory we are talking
about is shared memory, which cannot be grown after the server started
(like you can with the kind of memory served by malloc()).

Also, some people want the ability to stash messages with each NOTIFY.
This makes the whole idea a lot more complicated.

What this means is that nobody has tried *really hard* to make it work
(really hard meaning, enough so that it actually works).  Neil Conway
had some nice ideas but I don't think they were ever fully realized.

If you want to contribute, you're more than welcome.  You're far from
alone in wanting this thing "fixed."

--
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support


pgsql-general by date:

Previous
From: Thomas Burns
Date:
Subject: Re: pg_restore performance on solaris 10/6
Next
From: "Carlo Stonebanks"
Date:
Subject: Re: Best Procedural Language?