Search Postgresql Archives

Re: Performance of the listen command

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux