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 по дате отправления: