Received: from localhost (maia-2.hub.org [200.46.204.187]) by postgresql.org (Postfix) with ESMTP id 1AE239FB7C3 for ; Wed, 4 Apr 2007 14:36:57 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.187]) (amavisd-maia, port 10024) with ESMTP id 01532-06 for ; Wed, 4 Apr 2007 14:36:43 -0300 (ADT) X-Greylist: delayed 15:42:22.639672 by SQLgrey-1.7.4 Received: from mail.polimetrix.com (mail.polimetrix.com [209.128.109.230]) by postgresql.org (Postfix) with ESMTP id 63BAC9FB6DB for ; Wed, 4 Apr 2007 14:36:44 -0300 (ADT) Received: from [10.1.1.201] ([10.1.1.201]) by mail.polimetrix.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Apr 2007 10:36:37 -0700 Message-ID: <4613E224.7050301@polimetrix.com> Date: Wed, 04 Apr 2007 10:36:36 -0700 From: Geoff Tolley User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.10) Gecko/20070226 CentOS/1.0.8-0.2.el4.centos SeaMonkey/1.0.8 MIME-Version: 1.0 To: jason@ohloh.net CC: pgsql-performance@postgresql.org Subject: Re: SCSI vs SATA References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Apr 2007 17:36:37.0563 (UTC) FILETIME=[CBFF28B0:01C776DF] X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200704/81 X-Sequence-Number: 23958 jason@ohloh.net wrote: > Good point. On another note, I am wondering why nobody's brought up > the command-queuing perf benefits (yet). Is this because sata vs scsi > are at par here? I'm finding conflicting information on this -- some > calling sata's ncq mostly crap, others stating the real-world results > are negligible. I'm inclined to believe SCSI's pretty far ahead here > but am having trouble finding recent articles on this. My personal thoughts are that the SATA NCQ opinion you've found is simply because the workloads SATAs tend to be given (single-user) don't really benefit that much from it. > The servers are hooked up to a reliable UPS. The battery-backed cache > won't hurt but might be overkill (?). The difference is that a BBU isn't going to be affected by OS/hardware hangs. There are even some SCSI RAID cards I've seen which can save your data in case the card itself fails (the BBU in these cases is part of the same module as the write cache memory, so you can remove them together and put them into a new card, after which the data can be written). I haven't checked into this recently, but IDE drives are notorious for lying about having their internal write cache disabled. Which means that in theory a BBU controller can have a write acknowledged as having happened, consequently purge the data from the write cache, then when the power fails the data still isn't on any kind of permanent storage. It depends how paranoid you are as to whether you care about this edge case (and it'd make rather less difference if the pg_xlog is on a non-lying drive). HTH, Geoff