Received: from localhost (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id C8A4D64FD31 for ; Fri, 2 Jan 2009 20:52:16 -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 54176-05 for ; Fri, 2 Jan 2009 20:52:14 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by mail.postgresql.org (Postfix) with ESMTP id EC0BB64FCF2 for ; Fri, 2 Jan 2009 20:52:13 -0400 (AST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id n030pd5B014489; Fri, 2 Jan 2009 19:51:39 -0500 (EST) To: Gregory Stark cc: Greg Smith , Robert Haas , ITAGAKI Takahiro , Postgres Subject: Re: posix_fadvise v22 In-reply-to: <878wptv3u6.fsf@oxford.xeocode.com> 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> Comments: In-reply-to Gregory Stark message dated "Fri, 02 Jan 2009 15:40:49 -0500" Date: Fri, 02 Jan 2009 19:51:39 -0500 Message-ID: <14488.1230943899@sss.pgh.pa.us> From: Tom Lane 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/87 X-Sequence-Number: 130731 Gregory Stark writes: > Tom Lane 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. 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. regards, tom lane