Re: Excessive PostmasterIsAlive calls slow down WAL redo
От | Stephen Frost |
---|---|
Тема | Re: Excessive PostmasterIsAlive calls slow down WAL redo |
Дата | |
Msg-id | 20180406113928.GM27724@tamriel.snowman.net обсуждение исходный текст |
Ответ на | Re: Excessive PostmasterIsAlive calls slow down WAL redo (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Excessive PostmasterIsAlive calls slow down WAL redo
|
Список | pgsql-hackers |
Greetings, * Andres Freund (andres@anarazel.de) wrote: > On 2018-04-05 14:39:27 -0400, Tom Lane wrote: > > Andres Freund <andres@anarazel.de> writes: > > > ISTM the better approach would be to try to reduce the cost of > > > PostmasterIsAlive() on common platforms - it should be nearly free if > > > done right. > > > > +1 if it's doable. [...] > > While it's not POSIX, at least some platforms are capable of delivering > > a separate signal on parent process death. Perhaps using that where > > available would be enough of an answer. > > Yea, that'd work on linux. Which is probably the platform 80-95% of > performance critical PG workloads run on. There's > JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE on windows, which might also work, > but I'm not sure it provides enough opportunity for cleanup. While I tend to agree that it'd be nice to just make it cheaper, that doesn't seem like something that we'd be likely to back-patch and I tend to share Heikki's feelings that this is a performance regression we should be considering fixing in released versions. What Alvaro posted up-thread seems like it might be a small enough change to still be reasonable to back-patch and we can still think about ways to make PostmasterIsAlive() cheaper in the future. Thanks! Stephen
Вложения
В списке pgsql-hackers по дате отправления: