Received: from maia.hub.org (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id 9CEB464325E for ; Wed, 17 Mar 2010 13:47:18 -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 21087-03 for ; Wed, 17 Mar 2010 16:47:06 +0000 (UTC) X-Greylist: delayed 00:05:17.257283 by SQLgrey-1.7.6 Received: from mail-pz0-f201.google.com (mail-pz0-f201.google.com [209.85.222.201]) by mail.postgresql.org (Postfix) with ESMTP id 81F14633A5A for ; Wed, 17 Mar 2010 13:47:07 -0300 (ADT) Received: by pzk39 with SMTP id 39so858933pzk.15 for ; Wed, 17 Mar 2010 09:47:06 -0700 (PDT) Received: by 10.115.36.31 with SMTP id o31mr1091856waj.171.1268844108320; Wed, 17 Mar 2010 09:41:48 -0700 (PDT) Received: from Craig-Jamess-MacBook-Pro.local (wsip-70-167-124-126.sd.sd.cox.net [70.167.124.126]) by mx.google.com with ESMTPS id 12sm960221pwj.5.2010.03.17.09.41.45 (version=SSLv3 cipher=RC4-MD5); Wed, 17 Mar 2010 09:41:47 -0700 (PDT) Message-ID: <4BA10648.6010609@emolecules.com> Date: Wed, 17 Mar 2010 09:41:44 -0700 From: Craig James User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: pgsql-performance@postgresql.org Subject: Re: Block at a time ... References: <20100317001405.GL3037@alvh.no-ip.org> <407d949e1003170252y72d223c3kcc18266140a60997@mail.gmail.com> In-Reply-To: <407d949e1003170252y72d223c3kcc18266140a60997@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.67 tagged_above=-10 required=5 tests=AWL=0.930, BAYES_00=-2.599 X-Spam-Level: X-Archive-Number: 201003/202 X-Sequence-Number: 38027 On 3/17/10 2:52 AM, Greg Stark wrote: > On Wed, Mar 17, 2010 at 7:32 AM, Pierre C wrote: >>> I was thinking in something like that, except that the factor I'd use >>> would be something like 50% or 100% of current size, capped at (say) 1 GB. > > This turns out to be a bad idea. One of the first thing Oracle DBAs > are told to do is change this default setting to allocate some > reasonably large fixed size rather than scaling upwards. > > This might be mostly due to Oracle's extent-based space management but > I'm not so sure. Recall that the filesystem is probably doing some > rounding itself. If you allocate 120kB it's probably allocating 128kB > itself anyways. Having two layers rounding up will result in odd > behaviour. > > In any case I was planning on doing this a while back. Then I ran some > experiments and couldn't actually demonstrate any problem. ext2 seems > to do a perfectly reasonable job of avoiding this problem. All the > files were mostly large contiguous blocks after running some tests -- > IIRC running pgbench. This is one of the more-or-less solved problems in Unix/Linux. Ext* file systems have a "reserve" usually of 10% of the disk space that nobody except root can use. It's not for root, it's because with 10% of the disk free, you can almost always do a decent job of allocating contiguous blocks and get good performance. Unless Postgres has some weird problem that Linux has never seen before (and that wouldn't be unprecedented...), there's probably no need to fool with file-allocation strategies. Craig