Received: from maia.hub.org (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id A22DE65B32F for ; Tue, 16 Mar 2010 19:21:17 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 20459-09 for ; Tue, 16 Mar 2010 22:21:06 +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 F08B565B127 for ; Tue, 16 Mar 2010 19:21:06 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by spinlock.commandprompt.com (Postfix) with ESMTP id DABA634803D; Tue, 16 Mar 2010 15:21:04 -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 n9d0Ht4PMy6s; Tue, 16 Mar 2010 15:21:04 -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 7684F34803A; Tue, 16 Mar 2010 15:21:04 -0700 (PDT) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id 62CE46E4BD; Tue, 16 Mar 2010 19:20:58 -0300 (CLST) Date: Tue, 16 Mar 2010 19:20:58 -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: <20100316222058.GI3037@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> <20100316214903.GH3037@alvh.no-ip.org> <15417.1268776714@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <15417.1268776714@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.599 tagged_above=-10 required=5 tests=BAYES_00=-2.599 X-Spam-Level: X-Archive-Number: 201003/181 X-Sequence-Number: 38006 Tom Lane escribió: > Alvaro Herrera writes: > > Tom Lane escribió: > >> 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. > > fsync is a file-based operation, and we know exactly zip about the > relative positions of different files on the disk. Doh, right, I was thinking in the sync-file-range kind of API. > > 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. > > That's not going to do anything towards reducing the actual I/O volume. > Although I suppose it might be useful if it just cuts the number of > seeks. Oh, they had no problems with I/O volume. It was relation extension lock that was heavily contended for them. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support