Received: from localhost (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id C45A964FC2A for ; Sat, 3 Jan 2009 00:15:19 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 86069-03 for ; Sat, 3 Jan 2009 00:15:15 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.250]) by mail.postgresql.org (Postfix) with ESMTP id 73D1E64FC25 for ; Sat, 3 Jan 2009 00:15:14 -0400 (AST) Received: by an-out-0708.google.com with SMTP id d14so1944194and.28 for ; Fri, 02 Jan 2009 20:15:13 -0800 (PST) Received: by 10.65.157.19 with SMTP id j19mr14280283qbo.39.1230956113237; Fri, 02 Jan 2009 20:15:13 -0800 (PST) Received: from oxford.xeocode.com.enterprisedb.com (76-10-172-69.dsl.teksavvy.com [76.10.172.69]) by mx.google.com with ESMTPS id k29sm32391508qba.7.2009.01.02.20.15.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 02 Jan 2009 20:15:12 -0800 (PST) To: Tom Lane Cc: Greg Smith , Robert Haas , ITAGAKI Takahiro , Postgres Subject: Re: posix_fadvise v22 In-Reply-To: <14488.1230943899@sss.pgh.pa.us> (Tom Lane's message of "Fri\, 02 Jan 2009 19\:51\:39 -0500") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) X-Draft-From: ("nnimap+imap.gmail.com:HACKERS" 52305) References: <8347.1229012970@sss.pgh.pa.us> <4136ffa0812110911x4914a951o6ca502879e3dede7@mail.gmail.com> <87k5a6tmy7.fsf@oxford.xeocode.com> <603c8f070901011230t1afa6644racb715b975078054@mail.gmail.com> <10658.1230843315@sss.pgh.pa.us> <603c8f070901011843p121e40afu35c4a7bdc51c051c@mail.gmail.com> <24481.1230910405@sss.pgh.pa.us> <7537.1230926505@sss.pgh.pa.us> <878wptv3u6.fsf@oxford.xeocode.com> <14488.1230943899@sss.pgh.pa.us> From: Gregory Stark Organization: EnterpriseDB Date: Fri, 02 Jan 2009 23:15:10 -0500 Message-ID: <87mye9t48h.fsf@oxford.xeocode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200901/103 X-Sequence-Number: 130747 Tom Lane 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!