On Thu, Nov 17, 2011 at 11:17 AM, Aidan Van Dyk <aidan(at)highrise(dot)ca> wrote:
> But remember, you're doing all that in a single query. So your disk
> subsystem might even be able to perform even more *througput* if it
> was given many more concurrent request. A big raid10 is really good
> at handling multiple concurrent requests. But it's pretty much
> impossible to saturate a big raid array with only a single read
The query uses a bitmap heap scan, which means it would benefit from a
What's your effective_io_concurrency setting?
A good place to start setting it is the number of spindles on your
array, though I usually use 1.5x that number since it gives me a
little more thoughput.
You can set it on a query-by-query basis too, so you don't need to
change the configuration. If you do, a reload is enough to make PG
pick it up, so it's an easy thing to try.
In response to
pgsql-performance by date
|Next:||From: Jon Nelson||Date: 2011-11-17 17:10:56|
|Subject: external sort performance|
|Previous:||From: Tomas Vondra||Date: 2011-11-17 16:05:31|
|Subject: Re: Performance question 83 GB Table 150 million rows,