Received: from maia.hub.org (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id F395263EFF1 for ; Tue, 16 Mar 2010 18:58:51 -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 28387-09 for ; Tue, 16 Mar 2010 21:58:35 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by mail.postgresql.org (Postfix) with ESMTP id 454DC632AFB for ; Tue, 16 Mar 2010 18:58:41 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id o2GLwYf3015418; Tue, 16 Mar 2010 17:58:34 -0400 (EDT) To: Alvaro Herrera cc: Greg Stark , Pierre C , Greg Smith , Dave Crooke , Paul McGarry , pgsql-performance@postgresql.org Subject: Re: shared_buffers advice In-reply-to: <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> <20100316214903.GH3037@alvh.no-ip.org> Comments: In-reply-to Alvaro Herrera message dated "Tue, 16 Mar 2010 18:49:03 -0300" Date: Tue, 16 Mar 2010 17:58:34 -0400 Message-ID: <15417.1268776714@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-2.459 tagged_above=-10 required=5 tests=AWL=0.140, BAYES_00=-2.599 X-Spam-Level: X-Archive-Number: 201003/180 X-Sequence-Number: 38005 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. > However, this reminds me that sometimes we take the block-at-a-time > extension policy too seriously. Yeah, that's a huge performance penalty in some circumstances. > 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. regards, tom lane