Received: from localhost (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id E074F635788 for ; Fri, 13 Mar 2009 10:43:15 -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 75140-01-3 for ; Fri, 13 Mar 2009 10:43:03 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by mail.postgresql.org (Postfix) with SMTP id 63699635096 for ; Fri, 13 Mar 2009 10:43:07 -0300 (ADT) Received: from source ([64.233.182.189]) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKSbpi6NO7mPzdRibYY399ikj4RS+4GfSX@postini.com; Fri, 13 Mar 2009 06:43:07 PDT Received: by nf-out-0910.google.com with SMTP id c10so821216nfd.37 for ; Fri, 13 Mar 2009 06:43:04 -0700 (PDT) Received: by 10.216.48.1 with SMTP id u1mr657720web.189.1236951784004; Fri, 13 Mar 2009 06:43:04 -0700 (PDT) Received: from oxford.xeocode.com.enterprisedb.com ([82.16.16.210]) by mx.google.com with ESMTPS id g12sm3351252nfb.41.2009.03.13.06.43.03 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 13 Mar 2009 06:43:03 -0700 (PDT) To: "Jignesh K. Shah" Cc: Greg Smith , "pgsql-performance\@postgresql.org" Subject: Re: 8.4 Performance improvements: was Re: Proposal of tunable fix for scalability of 8.4 In-Reply-To: <49BA5537.8060002@sun.com> (Jignesh K. Shah's message of "Fri\, 13 Mar 2009 08\:44\:39 -0400") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) X-Draft-From: ("nnimap+imap.gmail.com:PG" 112936) References: <49B922C0.6050700@sun.com> <49BA5537.8060002@sun.com> From: Gregory Stark Organization: EnterpriseDB Date: Fri, 13 Mar 2009 13:43:01 +0000 Message-ID: <87vdqd4jyy.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: 200903/156 X-Sequence-Number: 33078 "Jignesh K. Shah" writes: > Can we do a vote on which specific performance features we want to test? > > Many of the improvements may not be visible through this standard tests so > feedback on testing methology for those is also appreciated. > * Visibility map - Reduce Vacuum overhead - (I think I can time vacuum with > some usage on both databases) Timing vacuum is kind of pointless -- the only thing that matters is whether it's "fast enough". But it is worth saying that good benchmarks should include normal vacuum runs. Benchmarks which don't run long enough to trigger vacuum aren't realistic. > * Prefetch IO with posix_fadvice () - Though I am not sure if it is supported > on UNIX or not (but can be tested by standard tests) Well clearly this is my favourite :) 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. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication support!