Re: listen/notify argument (old topic revisited)

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: listen/notify argument (old topic revisited)
Дата
Msg-id 200207022112.g62LCm423264@candle.pha.pa.us
обсуждение исходный текст
Ответ на Re: listen/notify argument (old topic revisited)  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: listen/notify argument (old topic revisited)  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: listen/notify argument (old topic revisited)  (Rod Taylor <rbt@zort.ca>)
Список pgsql-hackers
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?

> A shared memory system would use sequential (well, actually
> circular-buffer) access, which is *exactly* what you want given
> the inherently sequential nature of the messages.  The reason that
> table storage hurts is that we are forced to do searches, which we
> could eliminate if we had control of the storage ordering.  Again,
> it comes down to the fact that tables don't provide the right
> abstraction for this purpose.

To me, it just seems like going to shared memory is taking our existing
table structure and moving it to memory.  Yea, there is no tuple header,
and yea we can make a circular list, but we can't index the thing, so is
spinning around a circular list any better than a sequential scan of a
table.  Yea, we can delete stuff better, but autovacuum would help with
that.  It just seems like we are reinventing the wheel.

Are there other uses for this? Can we make use of RAM-only tables?

> The "extra code" argument doesn't impress me either; async.c is
> currently 900 lines, about 2.5 times the size of sinvaladt.c which is
> the guts of SI message passing.  I think it's a good bet that a SI-like
> notify module would be much smaller than async.c is now; it's certainly
> unlikely to be significantly larger.
> 
> The queue limit problem is a valid argument, but it's the only valid
> complaint IMHO; and it seems a reasonable tradeoff to make for the
> other advantages.

I am just not excited about it.  What do others think?

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 




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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: listen/notify argument (old topic revisited)
Следующее
От: Tom Lane
Дата:
Сообщение: Re: listen/notify argument (old topic revisited)