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

Re: Tuning Postgres 9.1 on Windows

From: "Walker, James Les" <JAWalker(at)cantor(dot)com>
To: 'Merlin Moncure' <mmoncure(at)gmail(dot)com>
Cc: Thomas Kellerer <spam_eater(at)gmx(dot)net>, "pgsql-performance(at)postgresql(dot)org"<pgsql-performance(at)postgresql(dot)org>
Subject: Re: Tuning Postgres 9.1 on Windows
Date: 2012-05-01 14:44:15
Message-ID: 21BFB59709EBB84DB412ED7F739FFD3B1AC403@TBPINFN0203.cad.local (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
I installed the enterprisedb distribution and immediately saw a 400% performance increase. Turning off fsck made it an order of magnitude better. I'm now peaking at over 400 commits per second. Does that sound right?

If I understand what you're saying, then to sustain this high rate I'm going to need a controller that can defer fsync requests from the host because it has some sort of battery backup that guarantees the full write.

-- Les

-----Original Message-----
From: Merlin Moncure [mailto:mmoncure(at)gmail(dot)com] 
Sent: Tuesday, May 01, 2012 9:43 AM
To: Walker, James Les
Cc: Thomas Kellerer; pgsql-performance(at)postgresql(dot)org
Subject: Re: [PERFORM] Tuning Postgres 9.1 on Windows

On Tue, May 1, 2012 at 8:14 AM, Walker, James Les <JAWalker(at)cantor(dot)com> wrote:
> SSD is OCZ-VERTEX3 MI. Controller is LSI SAS2 2008 Falcon. I'm working on installing EDB. Then I can give you some I/O numbers.

It looks like the ssd doesn't have a nv cache and the raid card is a simple sas hba (which likely isn't doing much for the ssd besides masking TRIM).  The OCZ 'pro' versions are the ones with power loss protection (see:
 Note the bullet: "Implements SandForce 2582 Controller with power loss data protection".  It doesn't look like the Vertex 3 Pro is out yet.

If my hunch is correct, the issue here is that the drive is being asked to sync data physically and SSD really don't perform well when the controller isn't in control of when and how to sync data.  However full physical sync is the only way to guarantee data is truly safe in the context of a unexpected power loss (an nv cache is basically a compromise on this point).

CONFIDENTIAL: This e-mail, including its contents and attachments, if any, are confidential. If you are not the named recipient please notify the sender and immediately delete it. You may not disseminate, distribute, or forward this e-mail message or disclose its contents to anybody else. Copyright and any other intellectual property rights in its contents are the sole property of Cantor Fitzgerald.
     E-mail transmission cannot be guaranteed to be secure or error-free. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission.  If verification is required please request a hard-copy version.
     Although we routinely screen for viruses, addressees should check this e-mail and any attachments for viruses. We make no representation or warranty as to the absence of viruses in this e-mail or any attachments. Please note that to ensure regulatory compliance and for the protection of our customers and business, we may monitor and read e-mails sent to and from our server(s). 

For further important information, please see

In response to


pgsql-performance by date

Next:From: Clemens EissererDate: 2012-05-01 15:04:57
Subject: Re: Any disadvantages of using =ANY(ARRAY()) instead of IN?
Previous:From: Tom LaneDate: 2012-05-01 14:43:58
Subject: Re: Any disadvantages of using =ANY(ARRAY()) instead of IN?

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