Date: Wed, 9 Jan 2008 13:44:34 -0500 (EST)
From: Greg Smith <gsmith@gregsmith.com>
cc: pgsql-performance@postgresql.org
Subject: Re: big database performance
In-Reply-To: <1d4e0c10801090859l55b35082r5992a1bb81f1ec32@mail.gmail.com>
Message-ID: <Pine.GSO.4.64.0801091329330.13584@westnet.com>
References: <4784835A.8070604@careerjunction.co.za>
	<47848575.8000007@commandprompt.com>
	<1d4e0c10801090859l55b35082r5992a1bb81f1ec32@mail.gmail.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Wed, 9 Jan 2008, Guillaume Smet wrote:

> On Jan 9, 2008 9:27 AM, Joshua D. Drake <jd@commandprompt.com> wrote:
>> wal_sync_method = open_sync
>
> Do you recommend it in every situation or just because data are on a
> SAN? Do you have any numbers/real cases explaining this choice.

Sync writes are faster on Linux in every case I've ever tried, compared to 
the default config that does a write followed by a sync.  With regular 
discs they're just a little faster.  On some SAN configurations, they're 
enormously faster, because the SANs are often optimized to handle 
syncronous writes far more efficiently than write/sync ones.  This is 
mainly because Oracle does its writes that way, so if you want good Oracle 
performance you have to handle sync writes well.

I have something on this topic I keep meaning to publish, but I got 
spooked about the potential to have silent problems or crashes when using 
open_sync due to a Linux kernel issue reported here:

http://archives.postgresql.org/pgsql-hackers/2007-10/msg01310.php

Certainly with that report floating out there I'd only recommend open_sync 
to people who are putting plenty of time into testing their database is 
robust under load with that configuration before deploying it; I sure 
wouldn't just make that changes on a production system just to see if it's 
faster.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD