Re: patch: improve SLRU replacement algorithm

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: patch: improve SLRU replacement algorithm
Дата
Msg-id CAM-w4HOB6g+73yceVdr6ZBe1kBjSFX5Xkigy=h+wL8jr9YSJKw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: patch: improve SLRU replacement algorithm  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: patch: improve SLRU replacement algorithm  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Thu, Apr 5, 2012 at 3:05 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> I'm not sure I find those numbers all that helpful, but there they
> are.  There are a couple of outliers beyond 12 s on the patched run,
> but I wouldn't read anything into that; the absolute worst values
> bounce around a lot from test to test.  However, note that every
> bucket between 2s and 8s improves, sometimes dramatically.

The numbers seem pretty compelling to me. They seem to indicate that
you've killed one of the big source of stalls but that there are more
lurking including at least one which causes small number of small
stalls.

The only fear I have is that I'm still wondering what happens to your
code when *all* the buffers become blocked on I/O. Can you catch
whether this ever occurred in your test and explain what should happen
in that case?

--
greg


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

Предыдущее
От: Jeff Janes
Дата:
Сообщение: Re: patch: improve SLRU replacement algorithm
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Speed dblink using alternate libpq tuple storage