Re: posix_fadvise v22 - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: posix_fadvise v22
Date
Msg-id 878wptv3u6.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: posix_fadvise v22  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: posix_fadvise v22  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.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


pgsql-hackers by date:

Previous
From: "Robert Haas"
Date:
Subject: Re: Significantly larger toast tables on 8.4?
Next
From: Bruce Momjian
Date:
Subject: Re: posix_fadvise v22