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.
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.
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.
regards, tom lane
