From: | Rod Taylor <rbt(at)zort(dot)ca> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jeff Davis <list-pgsql-hackers(at)empires(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: listen/notify argument (old topic revisited) |
Date: | 2002-07-03 11:18:44 |
Message-ID: | 1025695125.232.497.camel@jester |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 2002-07-02 at 17:12, Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Rod Taylor | 2002-07-03 11:24:50 | Re: BETWEEN Node & DROP COLUMN |
Previous Message | Hannu Krosing | 2002-07-03 10:53:25 | Re: listen/notify argument (old topic revisited) |