Received: from localhost (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id DCC556322EB for ; Fri, 13 Mar 2009 12:37:52 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 06965-03 for ; Fri, 13 Mar 2009 12:37:47 -0300 (ADT) X-Greylist: delayed 00:17:22.258075 by SQLgrey-1.7.6 Received: from centaur.rentec.com (centaur.rentec.com [216.223.240.8]) by mail.postgresql.org (Postfix) with ESMTP id 98875634332 for ; Fri, 13 Mar 2009 12:37:46 -0300 (ADT) Received: from papyrus1.rentec.com ([172.18.66.18]) by centaur.rentec.com (8.13.6/8.12.1) with ESMTP id n2DFJQMn012884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Mar 2009 11:19:27 -0400 (EDT) X-Source: non-mednet Received: from [172.18.83.46] (sycamore.rentec.com [172.18.83.46]) by papyrus1.rentec.com (8.14.3/8.14.0/SuSE Linux 0.8) with ESMTP id n2DFK4ji014106; Fri, 13 Mar 2009 11:20:04 -0400 Message-ID: <49BA79A4.9030208@rentec.com> Date: Fri, 13 Mar 2009 11:20:04 -0400 From: Alan Stange User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.4) Gecko/20070620 Thunderbird/2.0.0.4 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Gregory Stark CC: "Jignesh K. Shah" , Greg Smith , "pgsql-performance@postgresql.org" Subject: Re: 8.4 Performance improvements: was Re: Proposal of tunable fix for scalability of 8.4 References: <49B922C0.6050700@sun.com> <49BA5537.8060002@sun.com> <87prgl4jbh.fsf@oxford.xeocode.com> In-Reply-To: <87prgl4jbh.fsf@oxford.xeocode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Logged: Logged by centaur.rentec.com as n2DFJQMn012884 at Fri Mar 13 11:19:27 2009 X-Brightmail-Tracker: AAAAAQAAAAQ= X-Whitelist: TRUE 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: 200903/160 X-Sequence-Number: 33082 Gregory Stark wrote: > A minute ago I said: > > AFAIK Opensolaris doesn't implement posix_fadvise() so there's no benefit. It > would be great to hear if you could catch the ear of the right people to get > an implementation committed. Depending on how the i/o scheduler system is > written it might not even be hard -- the Linux implementation of WILLNEED is > all of 20 lines. > > I noticed after sending it that that's slightly unfair. The 20-line function > calls another function (which calls another function) to do the real readahead > work. That function (mm/readahead.c:__do_page_cache_readahead()) is 48 lines. > > It's implemented. I'm guessing it's not what you want to see though: http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/port/gen/posix_fadvise.c