Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> In principle you should be able to adjust the constant so that vmstat
> shows about 50% CPU busy, and then enabling fadvise should improve
> matters significantly.

I think in practice individual queries don't interleave much cpu with i/o
work. A single random page fetch is 5ms which is an awful lot of cpu cycles to
be sinking somewhere. In practice I think this is going to be single-digit
percentages.

Aside from big sorts and such which tend not to be interleaved with i/o the
main time I've seen queries have a significant cpu load is when the data is
mostly in cache. In which case prefetching would be hard pressed to help at
all.

We could construct a synthetic case but the main point of this feature is to
make use of raid arrays that are currently going idle, not to pick up a few
percentage points for single spindle systems.

-- 
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com
  Ask me about EnterpriseDB's On-Demand Production Tuning

In response to

• Re: posix_fadvise v22 at 2009-01-02 20:01:45 from Tom Lane

Responses

• Re: posix_fadvise v22 at 2009-01-03 00:51:39 from Tom Lane

pgsql-hackers by date

Next:	From: Bruce Momjian	Date: 2009-01-02 20:43:41
	Subject: Re: posix_fadvise v22
Previous:	From: Robert Haas	Date: 2009-01-02 20:35:18
	Subject: Re: Significantly larger toast tables on 8.4?