4 ms·
If you mean the optimizations coming in Postgres 19, the original post addresses this: > As an aside, there’s been some online discussion of a Postgres patch (
by KraftyOne 2mo ago
If you mean the optimizations coming in Postgres 19, the original post addresses this:
> As an aside, there’s been some online discussion of a Postgres patch (https://github.com/postgres/postgres/commit/282b1cde9dedf456ecf02eb27caf086023a7bb71 https://github.com/postgres/postgres/commit/282b1cde9dedf456...) related to this issue. This patch (to be released in Postgres 19) does not remove the global lock or fix the bottleneck we observed. Instead, it optimizes the narrower case where there are many notification channels and each listener is waiting only on a specific channel.
- JoelJacobson 2mo agoIt did fix the original "Postgres LISTEN/NOTIFY does not scale" [1] post's problem though, which was mentioned in an update of that article: Update: Fixed in Postgres core This commit has eliminated the bottleneck in the postgres core. Credit to Joel Jacobson and the core postgres contributors for resolving this. [1] https://www.recall.ai/blog/postgres-listen-notify-does-not-scale https://www.recall.ai/blog/postgres-listen-notify-does-not-s...