Re: listen/notify argument (old topic revisited)

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > Why can't we do efficient indexing, or clear out the table? I don't
> > remember.
>
> I don't recall either, but I do recall that we tried to index it and
> backed out the changes. In any case, a table on disk is just plain
> not the right medium for transitory-by-design notification messages.

OK, I can help here. I added an index on pg_listener so lookups would
go faster in the backend, but inserts/updates into the table also
require index additions, and your feeling was that the table was small
and we would be better without the index and just sequentially scanning
the table. I can easily add the index and make sure it is used properly
if you are now concerned about table access time.

I think your issue was that it is only looked up once, and only updated
once, so there wasn't much sense in having that index maintanance
overhead, i.e. you only used the index once per row.

(I remember the item being on TODO for quite a while when we discussed
this.)

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.

> >> 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.
>
> The SI message mechanism itself was not the source of bugs, as I recall
> it (although certainly the code was incomprehensible in the extreme;
> the original programmer had absolutely no grasp of readable coding style
> IMHO). The problem was failure to properly design the interactions with
> relcache and catcache, which are pretty complex in their own right.
> An SI-like NOTIFY mechanism wouldn't have those issues.

Oh, OK, interesting. So _that_ was the issue there.

--
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