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

Re: which dual-CPU hardware/OS is fastest for PostgreSQL?

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: jd(at)commandprompt(dot)com,Merlin Moncure <merlin(dot)moncure(at)rcsonline(dot)com>, alex(at)neteconomist(dot)com,pgsql-performance(at)postgresql(dot)org
Subject: Re: which dual-CPU hardware/OS is fastest for PostgreSQL?
Date: 2005-03-28 23:37:54
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
Greg Stark wrote:
> "Joshua D. Drake" <jd(at)commandprompt(dot)com> writes:
> > > I assume AMCC == 3ware now?
> > > 
> > > Has anyone verified that fsync is safe on these controllers? Ie, that they
> > > aren't caching writes and "lying" about the write completing like IDE
> > > drives often do by default?
> > 
> > The higher end AMCC/3ware controllers actually warn you about using
> > write-cache. You have to explicitly turn it on within the controller
> > bios.
> Well that's a good sign.
> But if they're using SATA drives my concern is that the drives themselves may
> be doing some caching on their own. Has anyone verified that the controllers
> are disabling the drive cache or issuing flushes or doing something else to be
> sure to block the drives from caching writes?

I asked 3ware this at the Linuxworld Boston show and they said their
controller keeps the information in cache until they are sure it is on
the platters and not just in the disk cache, but that is far from a 100%
reliable report.

  Bruce Momjian                        |
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

In response to


pgsql-performance by date

Next:From: Hannes DorbathDate: 2005-03-29 00:15:01
Subject: Re: Query Optimizer Failure / Possible Bug
Previous:From: Simon RiggsDate: 2005-03-28 22:59:11
Subject: Re: Delete query takes exorbitant amount of time

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