Re: Performance of the listen command

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: Performance of the listen command
Дата
Msg-id 20060730164833.GB5906@surnet.cl
обсуждение исходный текст
Ответ на Re: Performance of the listen command  (Flemming Frandsen <ff@partyticket.net>)
Список 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 по дате отправления:

Предыдущее
От: Thomas Burns
Дата:
Сообщение: Re: pg_restore performance on solaris 10/6
Следующее
От: "Carlo Stonebanks"
Дата:
Сообщение: Re: Best Procedural Language?