Received: from maia.hub.org (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id A5EBB65B2F9 for ; Tue, 16 Mar 2010 18:49:19 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 27151-09 for ; Tue, 16 Mar 2010 21:49:03 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from spinlock.commandprompt.com (host-215.commandprompt.net [207.173.203.215]) by mail.postgresql.org (Postfix) with ESMTP id 08DE165B075 for ; Tue, 16 Mar 2010 18:49:08 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by spinlock.commandprompt.com (Postfix) with ESMTP id 530C234803D; Tue, 16 Mar 2010 14:49:06 -0700 (PDT) Received: from spinlock.commandprompt.com ([127.0.0.1]) by localhost (spinlock.commandprompt.com.commandprompt.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4gurXgG4V48b; Tue, 16 Mar 2010 14:49:06 -0700 (PDT) Received: from perhan.alvh.no-ip.org (200-85-214-83.bk4-dsl.surnet.cl [200.85.214.83]) by spinlock.commandprompt.com (Postfix) with ESMTPSA id E2DD534803A; Tue, 16 Mar 2010 14:49:05 -0700 (PDT) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id D18E56E4BD; Tue, 16 Mar 2010 18:49:03 -0300 (CLST) Date: Tue, 16 Mar 2010 18:49:03 -0300 From: Alvaro Herrera To: Tom Lane Cc: Greg Stark , Pierre C , Greg Smith , Dave Crooke , Paul McGarry , pgsql-performance@postgresql.org Subject: Re: shared_buffers advice Message-ID: <20100316214903.GH3037@alvh.no-ip.org> References: <4B9F3302.4020900@2ndquadrant.com> <8285.1268749832@sss.pgh.pa.us> <407d949e1003160753o6e5faa48rabaa42f7548029b7@mail.gmail.com> <20100316213054.GG3037@alvh.no-ip.org> <15102.1268775566@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <15102.1268775566@sss.pgh.pa.us> User-Agent: Mutt/1.5.20 (2009-06-14) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-2.558 tagged_above=-10 required=5 tests=AWL=0.041, BAYES_00=-2.599 X-Spam-Level: X-Archive-Number: 201003/179 X-Sequence-Number: 38004 Tom Lane escribió: > Alvaro Herrera writes: > > Maybe it would make more sense to try to reorder the fsync calls > > instead. > > Reorder to what, though? You still have the problem that we don't know > much about the physical layout on-disk. Well, to block numbers as a first step. However, this reminds me that sometimes we take the block-at-a-time extension policy too seriously. We had a customer that had a performance problem because they were inserting lots of data to TOAST tables, causing very frequent extensions. I kept wondering whether an allocation policy that allocated several new blocks at a time could be useful (but I didn't try it). This would also alleviate fragmentation, thus helping the physical layout be more similar to logical block numbers. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support