Skip site navigation (1) Skip section navigation (2)

Re: a heavy duty operation on an "unused" table kills my server

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 (view raw or flat)
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


In response to

Responses

pgsql-performance by date

Next:From: Kevin GrittnerDate: 2010-01-20 20:36:39
Subject: Re: New server to improve performance on our large and busy DB - advice?
Previous:From: Carlo StonebanksDate: 2010-01-20 20:03:27
Subject: Re: New server to improve performance on our large and busy DB - advice?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group