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
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 |