Subject: Re: Initial database loading and IDE x SCSI
From: Mark Lewis <mark.lewis@mir3.com>
To: carlosreimer@terra.com.br
Cc: pgsql-performance@postgresql.org
In-Reply-To: <PEEPKDFEHHEMKBBFPOOKCEHCCPAA.carlosreimer@terra.com.br>
References: <PEEPKDFEHHEMKBBFPOOKCEHCCPAA.carlosreimer@terra.com.br>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Organization: MIR3, Inc.
Date: Fri, 02 Jun 2006 11:41:27 -0700
Message-Id: <1149273687.20798.91.camel@archimedes>
Mime-Version: 1.0

On Fri, 2006-06-02 at 15:25 -0300, carlosreimer@terra.com.br wrote:
> Hi,
>=20
> I would like to know if my supposition is right.
>=20
> Considering an environment with only one hard disk attached to a server, =
an
> initial loading of the database probably is much faster using an IDE/ATA
> interface with write-back on than using an SCSI interface. That=C2=B4s be=
cause of
> the SCSI command interface overhead.

No, it's because the SCSI drive is honoring the database's request to
make sure the data is safe.

> Then main advantage of SCSI interfaces, the multiuser environment is lost=
 in
> this scenery.
>=20
> Am I right? Am I missing something here?
>=20
> Even if I=C2=B4m right, is something that could be done too improove SCSI=
 loading
> performance in this scenery?

You can perform the initial load in large transactions.  The extra
overhead for ensuring that data is safely written to disk will only be
incurred once per transaction, so try to minimize the number of
transactions.

You could optionally set fsync=3Doff in postgresql.conf, which means that
the SCSI drive will operate with no more safety than an IDE drive.  But
you should only do that if you're willing to deal with catastrophic data
corruption.  But if this is for a desktop application where you need to
support IDE drives, you'll need to deal with that anyway.

> Thanks in advance!
>=20
> Reimer
>=20
>=20
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend