Re: patch: improve SLRU replacement algorithm

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: patch: improve SLRU replacement algorithm
Дата
Msg-id CA+U5nMLMir-gZkzUpWQ7V4odBm7_q086TP1AA7emUPyKEVc9pA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: patch: improve SLRU replacement algorithm  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: patch: improve SLRU replacement algorithm
Список pgsql-hackers
On Thu, Apr 5, 2012 at 12:25 AM, Robert Haas <robertmhaas@gmail.com> wrote:

>> That seems much smarter. I'm thinking this should be back patched
>> because it appears to be fairly major, so I'm asking for some more
>> certainty that every thing you say here is valid. No doubt much of it
>> is valid, but that's not enough.
>
> Yeah, I was thinking about that.  What we're doing right now seems
> pretty stupid, so maybe it's worth considering a back-patch.  OTOH,
> I'm usually loathe to tinker with performance in stable releases.
> I'll defer to the opinions of others on this point.

I'm also loathe to back patch. But its not very often we find a
problem that causes all backends to wait behind a single I/O.

The wait-behind-I/O aspect is "OK" because that is what is designed to
happen. The unexpected bit is the point that the system *quickly*
switches around so that *all* backends choose to wait behind that same
I/O, which is mad.

There is no doubt that your I/Os are slow here and that the specific
test accentuates that, but neither of those things are rare.

If it was an optimiser bug that made something run in 10sec that
should have run in 10ms we fix it. So we fix this also.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: patch: improve SLRU replacement algorithm
Следующее
От: Joachim Wieland
Дата:
Сообщение: Re: parallel pg_dump