| From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
|---|---|
| To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
| Cc: | Dave Page <dpage(at)postgresql(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: notification payloads |
| Date: | 2007-03-26 16:43:58 |
| Message-ID: | 20070326164358.GD13471@alvh.no-ip.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2007-03-26 16:58:51 | Re: notification payloads |
| Previous Message | Weslee Bilodeau | 2007-03-26 16:38:29 | Partitioned tables constraint_exclusion |