Re: Optimize LISTEN/NOTIFY
От | Tom Lane |
---|---|
Тема | Re: Optimize LISTEN/NOTIFY |
Дата | |
Msg-id | 3095599.1758644879@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Optimize LISTEN/NOTIFY ("Joel Jacobson" <joel@compiler.org>) |
Ответы |
Re: Optimize LISTEN/NOTIFY
|
Список | pgsql-hackers |
[ getting back to this... ] "Joel Jacobson" <joel@compiler.org> writes: > I'm withdrawing the latest patches, since they won't fix the scalability > problems, but only provide some performance improvements by eliminating > redundant IPC signalling. This could also be improved outside of > async.c, by optimizing ProcSignal [1] or removing ProcSignal as > "Interrupts vs Signals" [2] is working on. > There seems to be two different scalability problems, that appears to be > orthogonal: > First, it's the thundering herd problems that I tried to solve initially > in this thread, by introducing a hash table in shared memory, to keep > track of what backends listen to what channels, to avoid immediate > wakeup of all listening backends for every notification. > Second, it's the heavyweight lock in PreCommit_Notify(), that prevents > parallelism of NOTIFY. Tom Lane has an idea [3] on how to improve this. 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? > 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. regards, tom lane
В списке pgsql-hackers по дате отправления: