From: | Greg Smith <greg(at)2ndquadrant(dot)com> |
---|---|
To: | Matthew Wakeling <matthew(at)flymine(dot)org> |
Cc: | Andy Colson <andy(at)squeakycode(dot)net>, Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: a heavy duty operation on an "unused" table kills my server |
Date: | 2010-01-20 20:34:21 |
Message-ID: | 4B5768CD.5030606@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Matthew Wakeling wrote:
> On Fri, 15 Jan 2010, Greg Smith wrote:
>> My theory has been that the "extra processing it has to perform" you
>> describe just doesn't matter in the context of a fast system where
>> physical I/O is always the bottleneck.
>
> Basically, to an extent, that's right. However, when you get 16 drives
> or more into a system, then it starts being an issue.
I guess if I test a system with *only* 16 drives in it one day, maybe
I'll find out.
Seriously though, there is some difference between a completely
synthetic test like you noted issues with here, and anything you can see
when running the database. I was commenting more on the state of things
from the perspective of a database app, where I just haven't seen any of
the CFQ issues I hear reports of in other contexts. I'm sure there are
plenty of low-level tests where the differences between the schedulers
is completely obvious and it doesn't look as good anymore, and I'll take
a look at whether I can replicate the test case you saw a specific
concern with here.
--
Greg Smith 2ndQuadrant Baltimore, MD
PostgreSQL Training, Services and Support
greg(at)2ndQuadrant(dot)com www.2ndQuadrant.com
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2010-01-20 20:36:39 | Re: New server to improve performance on our large and busy DB - advice? |
Previous Message | Carlo Stonebanks | 2010-01-20 20:03:27 | Re: New server to improve performance on our large and busy DB - advice? |