From: | Rishu Bagga <rishu(dot)postgres(at)gmail(dot)com> |
---|---|
To: | Joel Jacobson <joel(at)compiler(dot)org> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Optimize LISTEN/NOTIFY |
Date: | 2025-07-16 00:20:42 |
Message-ID: | CAK80=jhmE40KVqQ3ho37MArS7cAED1p9m7uikDxcnDmqdW7t8A@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi Joel,
Thanks for sharing the patch.
I have a few questions based on a cursory first look.
> If a single listener is found, we signal only that backend.
> Otherwise, we fall back to the existing broadcast behavior.
The idea of not wanting to wake up all backends makes sense to me,
but I don’t understand why we want this optimization only for the case
where there is a single backend listening on a channel.
Is there a pattern of usage in LISTEN/NOTIFY where users typically
have either just one or several backends listening on a channel?
If we are doing this optimization, why not maintain a list of backends
for each channel, and only wake up those channels?
Thanks,
Rishu
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Davis | 2025-07-16 00:34:41 | Collation and primary keys |
Previous Message | Noah Misch | 2025-07-16 00:19:57 | Re: Non-text mode for pg_dumpall |