Re: Performance of the listen command

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Flemming Frandsen <ff(at)partyticket(dot)net>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Performance of the listen command
Date: 2006-07-30 16:48:33
Message-ID: 20060730164833.GB5906@surnet.cl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2006-07-30 17:24:24 Re: Questions about update, delete, ctid...
Previous Message David Fetter 2006-07-30 16:27:15 Re: New variable server_version_num