Re: Opteron scaling with PostgreSQL - Mailing list pgsql-general

From Steve Wolfe
Subject Re: Opteron scaling with PostgreSQL
Date
Msg-id 40CA37CC.3090101@codon.com
Whole thread Raw
In response to Re: Opteron scaling with PostgreSQL  ("Dann Corbit" <DCorbit@connx.com>)
Responses Re: Opteron scaling with PostgreSQL  (Greg Stark <gsstark@mit.edu>)
List pgsql-general
> I would very much like to see the same test with Fsync on.
> A test that does not reflect real-world use has less value than one that
> just shows how fast it can go.
 >
 > For a read-only database, fsync could be turned off.  For any other
 > system it would be hair-brained and nobody in their right mind would
 > do it.

   Then I must not be in my right mind. : )

   Before I explain why *I* run with fsync turned off, the main reason
the tests were done without fsync was to test the scalability of the
Opteron platform, not the scalability of my disk subsystem. = )

   I've run with fsync off on my production servers for years.  Power
never goes off, and RAID 5 protects me from disk failures.  Sooner or
later, it may bite me in the butt.  We make backups sufficiently often
that the small amount of data we'll lose will be far offset by the
tremendous performance boost that we've enjoyed.  In fact, we even have
a backup server sitting there doing nothing, which can take over the
duties of the main DB server within a VERY short amount of time.

steve

pgsql-general by date:

Previous
From: "Dann Corbit"
Date:
Subject: Re: Opteron scaling with PostgreSQL
Next
From: "Gregory S. Williamson"
Date:
Subject: Re: Trying to minimize the impact of checkpoints (resend)