Re: patch: improve SLRU replacement algorithm - Mailing list pgsql-hackers

From Greg Stark
Subject Re: patch: improve SLRU replacement algorithm
Date
Msg-id CAM-w4HOB6g+73yceVdr6ZBe1kBjSFX5Xkigy=h+wL8jr9YSJKw@mail.gmail.com
Whole thread Raw
In response to Re: patch: improve SLRU replacement algorithm  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: patch: improve SLRU replacement algorithm  (Robert Haas <robertmhaas@gmail.com>)
List 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 by date:

Previous
From: Jeff Janes
Date:
Subject: Re: patch: improve SLRU replacement algorithm
Next
From: Tom Lane
Date:
Subject: Re: Speed dblink using alternate libpq tuple storage