Re: notification payloads

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