Re: listen/notify argument (old topic revisited)

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > I don't see a huge value to using shared memory. Once we get
> > auto-vacuum, pg_listener will be fine,
>
> No it won't. The performance of notify is *always* going to suck
> as long as it depends on going through a table. This is particularly
> true given the lack of any effective way to index pg_listener; the
> more notifications you feed through, the more dead rows there are
> with the same key...

Why can't we do efficient indexing, or clear out the table? I don't
remember.

> > and shared memory like SI is just
> > too hard to get working reliabily because of all the backends
> > reading/writing in there.
>
> A curious statement considering that PG depends critically on SI
> working. This is a solved problem.

My point is that SI was buggy for years until we found all the bugs, so
yea, it is a solved problem, but solved with difficulty.

Do we want to add another SI-type capability that could be as difficult
to get working properly, or will the notify piggyback on the existing SI
code. If that latter, that would be fine with me, but we still have the
overflow queue problem.

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