Re: Block at a time ...

From: Dave Crooke <dcrooke(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, Pierre C <lists(at)peufeu(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Block at a time ...
Date: 2010-03-17 15:16:00
Message-ID: ca24673e1003170816r4690672xc83252fa3f71b23d@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

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 <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Greg Stark <gsstark(at)mit(dot)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. 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
>

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Craig James 2010-03-17 16:41:44 Re: Block at a time ...
Previous Message VJK 2010-03-17 15:08:03 Fwd: shared_buffers advice