Received: from maia.hub.org (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 8C16C7992D4 for ; Wed, 17 Mar 2010 12:16:25 -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 32808-02-3 for ; Wed, 17 Mar 2010 15:16:15 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-bw0-f227.google.com (mail-bw0-f227.google.com [209.85.218.227]) by mail.postgresql.org (Postfix) with ESMTP id 221FE7992EA for ; Wed, 17 Mar 2010 12:16:01 -0300 (ADT) Received: by bwz27 with SMTP id 27so1127031bwz.17 for ; Wed, 17 Mar 2010 08:16:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=q/a5ck4bkY8TwAqRxM6CqtdHFocq5x6oUcW7/Hmso7g=; b=Q3AmJLUh2gFr58PSRDd4aWapAHwxuO+9EnYUIGczE0zKSJ8l54NboVSktjaVyFGtTZ iuEXNfM2h7SPWcf3QAGDf+2qxfh4GxIEtXslsFuutR0+zn1CzSPmw/adjDhHOrD5CbXC 2/f2Tix8c8aYeEQfcMyKS3xNOx8YBeHGbPxEQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=X8Zdj8uioGsT5ywFraocaY+TimabvU6Yb1E8BZ6TlEn73ai98qoXQs2U39QEtC+MYj MPEO+cPMlA5ClDJZCcJ268RR7xHSaVXpAhXENytEalD/kekzdI4WcRdik3MrRNpQ9fZW GPRGop8cA/UEk6AaM2DAKfkWOU2C9O8esnXRw= MIME-Version: 1.0 Received: by 10.204.5.213 with SMTP id 21mr1282730bkw.66.1268838960797; Wed, 17 Mar 2010 08:16:00 -0700 (PDT) In-Reply-To: <27894.1268836024@sss.pgh.pa.us> References: <20100317001405.GL3037@alvh.no-ip.org> <407d949e1003170252y72d223c3kcc18266140a60997@mail.gmail.com> <27894.1268836024@sss.pgh.pa.us> Date: Wed, 17 Mar 2010 10:16:00 -0500 Message-ID: Subject: Re: Block at a time ... From: Dave Crooke To: Tom Lane Cc: Greg Stark , Pierre C , Alvaro Herrera , pgsql-performance@postgresql.org Content-Type: multipart/alternative; boundary=001517588b34891a200482009798 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-2.598 tagged_above=-10 required=5 tests=BAYES_00=-2.599, HTML_MESSAGE=0.001 X-Spam-Level: X-Archive-Number: 201003/201 X-Sequence-Number: 38026 --001517588b34891a200482009798 Content-Type: text/plain; charset=ISO-8859-1 Greg - with Oracle, I always do fixed 2GB dbf's for poartability, and preallocate the whole file in advance. However, the situation is a bit different in that Oracle will put blocks from multiple tables and indexes in a DBF if you don't tell it differently. Tom - I'm not sure what Oracle does, but it literally writes the whole extent before using it .... I think they are just doing the literal equivalent of *dd if=/dev/zero* ... it takes several seconds to prep a 2GB file on decent storage. Cheers Dave On Wed, Mar 17, 2010 at 9:27 AM, Tom Lane wrote: > Greg Stark writes: > > I think we need posix_fallocate(). > > The problem with posix_fallocate (other than questionable portability) > is that it doesn't appear to guarantee anything at all about what is in > the space it allocates. Worst case, we might find valid-looking > Postgres data there (eg, because a block was recycled from some recently > dropped table). If we have to write something anyway to zero the space, > what's the point? > > regards, tom lane > --001517588b34891a200482009798 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Greg - with Oracle, I always do fixed 2GB dbf's for poartability, and p= reallocate the whole file in advance. However, the situation is a bit diffe= rent in that Oracle will put blocks from multiple tables and indexes in a D= BF if you don't tell it differently.

Tom - I'm not sure what Oracle does, but it literally writes the wh= ole extent before using it .... I think they are just doing the literal equ= ivalent of dd if=3D/dev/zero ... it takes several seconds to prep a = 2GB file on decent storage.

Cheers
Dave

On Wed, Mar 17, 2010 a= t 9:27 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Greg Stark <gsstark= @mit.edu> writes:
> I think we need posix_fallocate().

The problem with posix_fallocate (other than questionable portability= )
is that it doesn't appear to guarantee anything at all about what is in=
the space it allocates. =A0Worst case, we might find valid-looking
Postgres data there (eg, because a block was recycled from some recently dropped table). =A0If we have to write something anyway to zero the space,<= br> what's the point?

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0regards, tom lane

--001517588b34891a200482009798--