Re: Excessive PostmasterIsAlive calls slow down WAL redo

Поиск
Список
Период
Сортировка
Искать
От
Andres Freund
Тема
Re: Excessive PostmasterIsAlive calls slow down WAL redo
Дата
Msg-id
20180406163929.g3jho4t776k75qlg@alap3.anarazel.de
Ответ на
Список
Дерево обсуждения
Excessive PostmasterIsAlive calls slow down WAL redo Heikki Linnakangas <hlinnaka@iki.fi>
Re: Excessive PostmasterIsAlive calls slow down WAL redo Alvaro Herrera <alvherre@alvh.no-ip.org>
Re: Excessive PostmasterIsAlive calls slow down WAL redo Andres Freund <andres@anarazel.de>
Re: Excessive PostmasterIsAlive calls slow down WAL redo Tom Lane <tgl@sss.pgh.pa.us>
Re: Excessive PostmasterIsAlive calls slow down WAL redo Andres Freund <andres@anarazel.de>
Re: Excessive PostmasterIsAlive calls slow down WAL redo Stephen Frost <sfrost@snowman.net>
Re: Excessive PostmasterIsAlive calls slow down WAL redo Andres Freund <andres@anarazel.de>
Re: Excessive PostmasterIsAlive calls slow down WAL redo Heikki Linnakangas <hlinnaka@iki.fi>
Re: Excessive PostmasterIsAlive calls slow down WAL redo Stephen Frost <sfrost@snowman.net>
Re: Excessive PostmasterIsAlive calls slow down WAL redo Andres Freund <andres@anarazel.de>
Re: Excessive PostmasterIsAlive calls slow down WAL redo Alvaro Herrera <alvherre@alvh.no-ip.org>
Re: Excessive PostmasterIsAlive calls slow down WAL redo Andres Freund <andres@anarazel.de>
Re: Excessive PostmasterIsAlive calls slow down WAL redo Alvaro Herrera <alvherre@alvh.no-ip.org>
Re: Excessive PostmasterIsAlive calls slow down WAL redo Andres Freund <andres@anarazel.de>
Re: Excessive PostmasterIsAlive calls slow down WAL redo Thomas Munro <thomas.munro@enterprisedb.com>
Re: Excessive PostmasterIsAlive calls slow down WAL redo Andres Freund <andres@anarazel.de>
Re: Excessive PostmasterIsAlive calls slow down WAL redo Heikki Linnakangas <hlinnaka@iki.fi>
Re: Excessive PostmasterIsAlive calls slow down WAL redo Thomas Munro <thomas.munro@enterprisedb.com>
Re: Excessive PostmasterIsAlive calls slow down WAL redo Thomas Munro <thomas.munro@enterprisedb.com>
Re: Excessive PostmasterIsAlive calls slow down WAL redo Thomas Munro <thomas.munro@enterprisedb.com>
Re: Excessive PostmasterIsAlive calls slow down WAL redo Andres Freund <andres@anarazel.de>
Re: Excessive PostmasterIsAlive calls slow down WAL redo Thomas Munro <thomas.munro@enterprisedb.com>
Re: Excessive PostmasterIsAlive calls slow down WAL redo Thomas Munro <thomas.munro@enterprisedb.com>
Re: Excessive PostmasterIsAlive calls slow down WAL redo Michael Paquier <michael@paquier.xyz>
Re: Excessive PostmasterIsAlive calls slow down WAL redo Thomas Munro <thomas.munro@enterprisedb.com>
Re: Excessive PostmasterIsAlive calls slow down WAL redo Thomas Munro <thomas.munro@enterprisedb.com>
Re: Excessive PostmasterIsAlive calls slow down WAL redo Heikki Linnakangas <hlinnaka@iki.fi>
Re: Excessive PostmasterIsAlive calls slow down WAL redo Thomas Munro <thomas.munro@enterprisedb.com>
Re: Excessive PostmasterIsAlive calls slow down WAL redo Heikki Linnakangas <hlinnaka@iki.fi>
Re: Excessive PostmasterIsAlive calls slow down WAL redo Michael Paquier <michael@paquier.xyz>
Re: Excessive PostmasterIsAlive calls slow down WAL redo Simon Riggs <simon@2ndquadrant.com>
Hi,

On 2018-04-06 07:39:28 -0400, Stephen Frost wrote:
> 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.

I'm doubtful about fairly characterizing this as a performance bug. It's
not like we've O(n^2) behaviour on our hand, and if your replay isn't of
a toy workload normally that one syscall isn't going to make a huge
difference because you've actual IO and such going on.

I'm also doubtful that it's sane to just check every 32 records. There's
records that can take a good chunk of time, and just continuing for
another 31 records seems like a bad idea.

Greetings,

Andres Freund

В списке pgsql-hackers по дате отправления
От: Tom Lane
Дата:
От: Peter Eisentraut
Дата:
FAQ