Re: Optimize LISTEN/NOTIFY
| От | Chao Li | 
|---|---|
| Тема | Re: Optimize LISTEN/NOTIFY | 
| Дата | |
| Msg-id | 87E40BF8-8877-4DBD-9040-99AF8A4E6358@gmail.com обсуждение исходный текст  | 
		
| Ответ на | Re: Optimize LISTEN/NOTIFY ("Joel Jacobson" <joel@compiler.org>) | 
| Ответы | 
                	
            		Re: Optimize LISTEN/NOTIFY
            		
            		 | 
		
| Список | pgsql-hackers | 
> On Oct 28, 2025, at 14:41, Joel Jacobson <joel@compiler.org> wrote: > > On Tue, Oct 28, 2025, at 02:02, Chao Li wrote: >>>> From this perspective, we need to add a new field >>>> adviancingTillPos to QueueBackendStatus. (This field was also missing >>>> from my proposed patch). >>> >>> I'm doubtful yet another field is worth the added complexity cost. >>> >>> Before increasing the complexity further, I think we should first >>> try to simulate somewhat realistic workloads, to see if we actually >>> have a problem first. >>> >>> /Joel >>> >> >> I don’t think that’s extra complexity, IMO, that just ensure “direct >> advancement” to be fully functional. > > An extra field is by definition extra complexity; > If it's worth it depends on how much we would gain from it, > that's why I'm doubtful it's worth it. > > The extra adviancingTillPos field would only avoid wakeups in some > scenarios, if you study the example given by Arseniy, it's easy to see > why we would really need something like a the list of skip ranges > Arseniy suggested, per backend, for it to be complete, > but that's even more complexity. > > I don't think it's too bad for a backend to read through the entire > queue, even if it contains some entires that are not interesting, when a > backend is awaken, processing is fast, that's not the big cost here, > what really costs is the context switches. But I've been wrong before, > so could be wrong again of course. This is just based on my intuition. > >> But anyway, we should run some load tests to verify every solution to >> see how much they really improve. Do you already have or plan to work >> on a load test script? > > Yes, I'm currently working on a combined benchmark / correctness test suite. > Cool. Then we can run the benchmark and decide. Best regards, -- Chao Li (Evan) HighGo Software Co., Ltd. https://www.highgo.com/
В списке pgsql-hackers по дате отправления: