Re: Adding disks/xlog & index - Mailing list pgsql-performance

From Gregory Stark
Subject Re: Adding disks/xlog & index
Date
Msg-id 87ps4ojuao.fsf@oxford.xeocode.com
Whole thread Raw
In response to Adding disks/xlog & index  (lists@on-track.ca)
List pgsql-performance
<lists@on-track.ca> writes:

> Some questions on this:
> 1. Can the database survive loss/corruption of the xlog and indexes in a
> recoverable way? To save money (and because I won't need the throughput as
> much), I am thinking on making this index/wal/xlog drive a single cheap
> sata drive (or maybe a non-raided 15k scsi for 60% more money). However
> without the redundancy of a mirror I am concerned about drive failure.
> Loss of several mins of recent transactions in a serious crash is
> acceptable to be, but full/serious database corruption (the likes of fsync
> off) is not.

Losing any WAL that the database has fsynced is exactly like having fsync off.

> 2. Is there any point using a high performance (ie scsi) disk for this, or
> would the mirror containing the majority of the data still be the major
> bottleneck causing the disk usage to not exceed sata performance anyway?

Well that depends on your database traffic. In most databases the volume of
WAL traffic is substantially less than the i/o traffic to the data drives. So
you usually don't need to be able to sustain high i/o bandwidth to the WAL
drive.

However in some database loads the latency to the WAL drive does matter. This
is especially true if you're executing a lot of short transactions and
response time is critical. Especially if you aren't executing many such
transactions in parallel. So for example if you're processing a serial batch
of short transactions and committing each one as a separate transaction. In
that case you would want a drive that can fsync fast which either means a
battery backed cache or 15kRPM drive. It doesn't necessarily mean you need a
bit raid array though.


--
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com


pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: general PG network slowness (possible cure) (repost)
Next
From: Craig James
Date:
Subject: ECC RAM really needed?