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?
cheers
andrew
---------------------------(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
