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