Re: patch: improve SLRU replacement algorithm

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: patch: improve SLRU replacement algorithm
Date: 2012-04-05 09:41:08
Message-ID: CA+U5nMLMir-gZkzUpWQ7V4odBm7_q086TP1AA7emUPyKEVc9pA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Apr 5, 2012 at 12:25 AM, Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joachim Wieland 2012-04-05 10:32:07 Re: parallel pg_dump
Previous Message Simon Riggs 2012-04-05 09:34:16 Re: patch: improve SLRU replacement algorithm