Re: big database performance

From: Greg Smith <gsmith(at)gregsmith(dot)com>
To:
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: big database performance
Date: 2008-01-09 18:44:34
Message-ID: Pine.GSO.4.64.0801091329330.13584@westnet.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Wed, 9 Jan 2008, Guillaume Smet wrote:

> On Jan 9, 2008 9:27 AM, Joshua D. Drake <jd(at)commandprompt(dot)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(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Simon Riggs 2008-01-09 21:01:18 Re: big database performance
Previous Message Erik Jones 2008-01-09 18:06:35 Re: After Vacuum Analyse - Procedure performance notimproved - Innner select is faster