Re: Optimize LISTEN/NOTIFY
От | Joel Jacobson |
---|---|
Тема | Re: Optimize LISTEN/NOTIFY |
Дата | |
Msg-id | 0dc6a2cc-5216-4dc1-9dd2-430cafc6095b@app.fastmail.com обсуждение исходный текст |
Ответ на | Re: Optimize LISTEN/NOTIFY (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Optimize LISTEN/NOTIFY
|
Список | pgsql-hackers |
On Tue, Sep 23, 2025, at 18:27, Tom Lane wrote: > I concur that these are orthogonal issues, but I don't understand > why you withdrew your patches --- don't they constitute a solution > to the first scalability bottleneck? Thanks for getting back to this thread. I was unhappy with not finding a solution that would improve all use-cases, I had a feeling it would be possible to find one, and I think I've done so now. >> I guess my main question is if we think we should fix one problem first, >> then the other, both at the same time, or only one or the other? > > I imagine we'd eventually want to fix both, but it doesn't have to > be done in the same patch. I've attached a new patch with a new pragmatic approach, that specifically addresses the context switching cost. The patch is based upon the assumption that some extra LISTEN/NOTIFY latency would be acceptable by most users, as a trade-off, in order to improve throughput. One nice thing with this approach is that it has the potential to improve throughput both for users with just a single listening backend, and also for users with lots of listening backends. More details in the commit message of the patch. Curious to hear thoughts on this approach. /Joel
Вложения
В списке pgsql-hackers по дате отправления: