Received: from localhost (unknown [200.46.204.184]) by postgresql.org (Postfix) with ESMTP id 9B7042E0081 for ; Fri, 28 Mar 2008 08:27:02 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024) with ESMTP id 96955-04 for ; Fri, 28 Mar 2008 08:26:51 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from oxford.xeocode.com (87-127-95-198.no-dns-yet.enta.net [87.127.95.198]) by postgresql.org (Postfix) with ESMTP id 0D9412E0082 for ; Fri, 28 Mar 2008 08:26:57 -0300 (ADT) Received: from localhost ([127.0.0.1] helo=oxford.xeocode.com) by oxford.xeocode.com with esmtp (Exim 4.69) (envelope-from ) id 1JfCjW-0006zB-RW; Fri, 28 Mar 2008 11:26:54 +0000 To: "Simon Riggs" Cc: "Pg Hackers" Subject: Re: Commitfest patches In-Reply-To: <1206697482.4285.1518.camel@ebony.site> (Simon Riggs's message of "Fri\, 28 Mar 2008 09\:44\:42 +0000") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) X-Draft-From: ("nnimap+mail01.enterprisedb.com:INBOX" 73355) References: <87wsnnz046.fsf@oxford.xeocode.com> <1206697482.4285.1518.camel@ebony.site> From: Gregory Stark Organization: EnterpriseDB Date: Fri, 28 Mar 2008 11:26:54 +0000 Message-ID: <87od8zytq9.fsf@oxford.xeocode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200803/1161 X-Sequence-Number: 115962 "Simon Riggs" writes: > On Fri, 2008-03-28 at 09:08 +0000, Gregory Stark wrote: > >> A more invasive form of this patch would be to assign and pin a buffer when >> the preread is done. That would men subsequently we would have a pinned buffer >> ready to go and not need to go back to the buffer manager a second time. We >> would instead just "complete" the i/o by issuing a normal read call. > > So if posix_fadvise did nothing or there was a longer than optimal > delay, this would be a net loss. > > You'd need reasonable evidence that the posix_fadvise facility was a win > on all platforms and recent release levels before we could agree with > that. I posted a test program and asked for others to test it on various platforms and various sized raid arrays. matthew@flymine.org was the only person who bothered to run it and he only found a 16x speedup on his hardware. http://archives.postgresql.org/pgsql-performance/2008-01/msg00285.php (unfortunately our mail archives seem to have failed to archive his message, this is my followup to it) > I think we need a more thorough examination of this area before we > commit anything. Maybe you've done this, but I haven't seen the > analysis. Can you say more, please? Or at least say what you don't know, > so other experts listening can fill in the blanks. For heaven's sake. I've been posting about this for months. Search the archives for "RAID arrays and performance", "There's random access and then there's random access", and "Bitmap index scan preread using posix_fadvise". I described which interfaces worked on Linux and Solaris based on empirical tests. I posted source code for synthetic benchmarks so we could test it on a wide range of hardware. I posted graphs based on empirical results. I posted mathematical formulas analysing just how much preread would be expected to exercise a raid array fully. I'm not sure what else I can do to effect a more thorough examination. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's PostGIS support!