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

From Simon Riggs
Subject Re: patch: improve SLRU replacement algorithm
Date
Msg-id CA+U5nMLMir-gZkzUpWQ7V4odBm7_q086TP1AA7emUPyKEVc9pA@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
List 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 by date:

Previous
From: Simon Riggs
Date:
Subject: Re: patch: improve SLRU replacement algorithm
Next
From: Joachim Wieland
Date:
Subject: Re: parallel pg_dump