Re: listen/notify argument (old topic revisited)

Поиск
Список
Период
Сортировка
От Rod Taylor
Тема Re: listen/notify argument (old topic revisited)
Дата
Msg-id 1025695125.232.497.camel@jester
обсуждение исходный текст
Ответ на Re: listen/notify argument (old topic revisited)  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список pgsql-hackers
On Tue, 2002-07-02 at 17:12, Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > > Of course, a shared memory system probably is going to either do it
> > > sequentailly or have its own index issues, so I don't see a huge
> > > advantage to going to shared memory, and I do see extra code and a queue
> > > limit.
> > 
> > Disk I/O vs. no disk I/O isn't a huge advantage?  Come now.
> 
> My assumption is that it throws to disk as backing store, which seems
> better to me than dropping the notifies.  Is disk i/o a real performance
> penalty for notify, and is performance a huge issue for notify anyway,
> assuming autovacuum?

For me, performance would be one of the only concerns. Currently I use
two methods of finding changes, one is NOTIFY which directs frontends to
reload various sections of data, the second is a table which holds a
QUEUE of actions to be completed (which must be tracked, logged and
completed).

If performance wasn't a concern, I'd simply use more RULES which insert
requests into my queue table.





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

Предыдущее
От: Hannu Krosing
Дата:
Сообщение: Re: (A) native Windows port
Следующее
От: Rod Taylor
Дата:
Сообщение: Re: BETWEEN Node & DROP COLUMN