Re: Performance of the listen command

Поиск
Список
Период
Сортировка
От Flemming Frandsen
Тема Re: Performance of the listen command
Дата
Msg-id 44CC88D8.5070506@partyticket.net
обсуждение исходный текст
Ответ на Re: Performance of the listen command  (Christopher Browne <cbbrowne@acm.org>)
Ответы Re: Performance of the listen command  (Alvaro Herrera <alvherre@commandprompt.com>)
Список pgsql-general
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:)

Keeping the listener structure in memory wouldn't be too bad.

I'd guess that each connection that listens only needs a single
transaction pointer (64bit int or somesuch?) to point to the transaction
that it has caught up with.

Each transaction will need some way of recording what events were seen,
like:

* a bitmap of the events seen during that transaction (to be useful
you'd need a global string->bit table, this needs some way of
sharing/locking that global datastructure though).

* an ordered list of events seen to allow a simple binary search.
* a more complicated datastructure like a JudySL array

If you really want to save space then a lump of the pr-transaction
bitmaps can be merged if there are no listeners that point to those
transactions.



>>Any ideas, other than run VACUUM pg_listener every 10 minutes?
>
> Remarkably enough, that is exactly the solution that the Slony-I,
> which makes use of LISTEN/NOTIFY, uses.  The Slony-I cleanup thread
> vacuums pg_listener (and some other tables) every 10 minutes.

Damnit, I thought I was kidding:)

--
  Regards Flemming Frandsen - http://dion.swamp.dk - YAPH


В списке pgsql-general по дате отправления:

Предыдущее
От: Martijn van Oosterhout
Дата:
Сообщение: Re: Joining dates/times (was Re: Splitting Timestamps)
Следующее
От: Martijn van Oosterhout
Дата:
Сообщение: Re: Corrupted DB? could not open file pg_clog/####