On Tue, 2002-07-02 at 23:35, Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Is disk i/o a real performance > > penalty for notify, and is performance a huge issue for notify anyway, > > Yes, and yes. I have used NOTIFY in production applications, and I know > that performance is an issue. > > >> 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. > > BTW, it occurs to me that as long as we make this an independent message > buffer used only for NOTIFY (and *not* try to merge it with SI), we > don't have to put up with overrun-reset behavior. The overrun reset > approach is useful for SI because there are only limited times when > we are prepared to handle SI notification in the backend work cycle. > However, I think a self-contained NOTIFY mechanism could be much more > flexible about when it will remove messages from the shared buffer. > Consider this: > > 1. To send NOTIFY: grab write lock on shared-memory circular buffer.
Are you planning to have one circular buffer per listening backend ? Would that not be waste of space for large number of backends with long notify arguments ? -------------- Hannu ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
