Bruce Momjian <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly