On Wed, Jul 16, 2025, at 02:20, Rishu Bagga wrote:
> If we are doing this optimization, why not maintain a list of backends
> for each channel, and only wake up those channels?
Thanks for a contributing a great idea, it actually turned out to work
really well in practice!
The attached new v4 of t
On Wed, Jul 16, 2025, at 02:20, Rishu Bagga wrote:
> 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
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
hes, that together
>> seems to scale well for both common-channel and unique-channel scenarios:
>
> Thanks to the FreeBSD animal failing, I see I made a shared memory blunder.
> New squashed patch attached.
>
> /Joel
> Attachments:
> * 0001-Subject-Optimize-LISTEN-NOTIFY
D animal failing, I see I made a shared memory blunder.
New squashed patch attached.
/Joel
0001-Subject-Optimize-LISTEN-NOTIFY-signaling-for-scalabi-v3.patch
Description: Binary data
"Joel Jacobson" writes:
> The attached proof-of-concept patch proposes a straightforward
> optimization for the single-listener case. It introduces a shared-memory
> hash table mapping (dboid, channelname) to the ProcNumber of a single
> listener.
What does that do to the cost and parallelizabili
ners: 2020 TPS
1000 extra listeners: 238 TPS
0001-Optimize-LISTEN-NOTIFY-signaling-for-single-listener.patch:
0 extra listeners: 9152 TPS
10 extra listeners: 9352 TPS
100 extra listeners: 9320 TPS
1000 extra listeners: 8937 TPS
As you can see, the patched version's performance is near O(1) with
