Alvaro Herrera wrote:
Andrew Dunstan wrote:

Let's say we provide 100Kb for this (which is not a heck of a lot) , that the average notification might be, say, 40 bytes of name plus 60 bytes of message. Then we have room for about 1000 messages in the queue. This would get ugly only if backend presumably in the middle of some very long transaction, refused to pick up its messages despite prodding. But ISTM that means we just need to pick a few strategic spots that will call CHECK_FOR_NOTIFICATIONS() even in the middle of a transaction and store them locally.

Why have the name on each message?  Presumably names are going to be few
compared to the total number of messages, so maybe store the names in a
separate hash table and link them with a numeric identifier.  That gives
you room for a lot more messages.

Maybe, but at the cost of some considerable complexity ISTM, especially as this all needs to be in shared memory.

On any machine with significant workload a few Mb of memory would not be missed. How many messages do we reasonably expect to be in the queue? Judging by our usage here it would be a handful at most, but maybe others have far more intensive uses. Is anyone really doing notifies at a rate of many per second?



---------------------------(end of broadcast)---------------------------
TIP 1: 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

Reply via email to