Skip site navigation (1) Skip section navigation (2)

Re: WAL+Os on a single disk

From: Anj Adu <fotographs(at)gmail(dot)com>
To: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>
Cc: Matthew Wakeling <matthew(at)flymine(dot)org>, pgsql-performance(at)postgresql(dot)org
Subject: Re: WAL+Os on a single disk
Date: 2010-06-24 14:55:04
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
What would you recommend to do a quick test for this? (i.e WAL on
internal disk vs WALon the 12 disk raid array )?

On Thu, Jun 24, 2010 at 6:31 AM, Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> wrote:
> On Thu, Jun 24, 2010 at 5:14 AM, Matthew Wakeling <matthew(at)flymine(dot)org> wrote:
>> On Wed, 23 Jun 2010, Scott Marlowe wrote:
>>>> We have a 12 x 600G hot swappable disk system (raid 10)
>>>> and 2 internal disk  ( 2x 146G)
>>>> Does it make sense to put the WAL and OS on the internal disks
>>> So for us, the WAL and OS and logging on the same data set works well.
>> Generally, it is recommended that you put the WAL onto a separate disc to
>> the data. However, in this case, I would be careful. It may be that the 12
>> disc array is more capable. Specifically, it is likely that the 12-disc
>> array has a battery backed cache, but the two internal drives (RAID 1
>> presumably) do not. If this is the case, then putting the WAL on the
>> internal drives will reduce performance, as you will only be able to commit
>> a transaction once per revolution of the internal discs. In contrast, if the
>> WAL is on a battery backed cache array, then you can commit much more
>> frequently.
> This is not strictly true of the WAL, which writes sequentially and
> more than one transaction at a time.  As you said though, test it to
> be sure.

In response to


pgsql-performance by date

Next:From: Rajesh Kumar MallahDate: 2010-06-24 14:56:02
Subject: Re: cpu bound postgresql setup.
Previous:From: Greg SmithDate: 2010-06-24 13:57:50
Subject: Re: Write performance

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group