Re: posix_fadvise v22 - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: posix_fadvise v22
Date
Msg-id 87mye9t48h.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: posix_fadvise v22  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> writes:

> The point of the suggestion is to prove that the patch works as
> advertised.  How wide the sweet spot is for this test isn't nearly as
> interesting as proving that there *is* a sweet spot.  If you can't
> find one it suggests that either the patch or the local posix_fadvise
> doesn't work.

I posted tons of reproducible test cases with graphs of results for various
raid stripe widths a while back. There was a very slight benefit on a single
spindle at some prefetch depths but it wasn't very consistent and it varied
heavily depending on the prefetch depth.

I don't know what to make of this test. I don't know how to reproduce the same
data distribution, I have no idea what raid configuration it's been run on,
what version of what OS it's on, etc. It's quite possible posix_fadvise isn't
working on it, I don't know.

It's also possible the overhead of the extra buffer lookups and syscalls
outweight any benefit of overlapping i/o and cpu on a single spindle.

Trying to contrive a situation where a single spindle sees a significant
benefit is going to be very tricky. Avoiding caching effects and the
confounding effect of any overhead will make it hard to see a consistent
benefit without a raid array.

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support!


pgsql-hackers by date:

Previous
From: "Robert Haas"
Date:
Subject: Re: posix_fadvise v22
Next
From: "Greg Stark"
Date:
Subject: Re: posix_fadvise v22