Received: from maia.hub.org (maia-4.hub.org [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 00706632969 for ; Fri, 30 Apr 2010 19:12:00 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 28694-09 for ; Fri, 30 Apr 2010 22:11:52 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by mail.postgresql.org (Postfix) with ESMTP id CDE47633244 for ; Fri, 30 Apr 2010 19:11:51 -0300 (ADT) Received: from [192.168.0.105] (pool-96-244-14-10.bltmmd.fios.verizon.net [96.244.14.10]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0LoaZ0-1NRkzD0V0U-00fsfE; Sat, 01 May 2010 00:11:38 +0200 Message-ID: <4BDB5597.3040306@2ndquadrant.com> Date: Fri, 30 Apr 2010 18:11:35 -0400 From: Greg Smith User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: Scott Whitney CC: Scott Marlowe , pgsql-admin@postgresql.org, Anj Adu , john@journyx.com Subject: Re: more 10K disks or less 15K disks References: <7406251.326331272570680650.JavaMail.root@zimbra.int.journyx.com> In-Reply-To: <7406251.326331272570680650.JavaMail.root@zimbra.int.journyx.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX19YJgNM4BzSr9oDIJw9rpLdOKStK9GApeKRm0M Jemjm2YQSMUfhKO5l3mIQ/C3V70LnLRdHHa6U+O8gLL9vGbynb po5+iVNoRdoCxfuB+sPFumY/zjdLrzt X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.9 tagged_above=-10 required=5 tests=BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001 X-Spam-Level: X-Archive-Number: 201004/376 X-Sequence-Number: 34470 Scott Whitney wrote: > On the 10k vs 15k rpm disks, there's a _lot_ to be said about that. I don't want to start a flame war here, > but 15k versus 10k rpm hard drives does NOT equivocate to a 50% increase in read/write times, to say > the VERY least. > Your characterization is correct were there only the drives involved here, so no flames on your raw data. Once you've introduced a battery-backed write cache into the mix, this whole area becomes impossible to compute that way though, and it was that context I was commenting from at least. Those are good at turning random I/O into something more like sequential, as well as reducing the number of times you pay for rotational latency in several common database operations. The effective impact is to significantly narrow the difference between drives where the seek and rotation time are the main differences in a database context--even though the worst-case IOPS doesn't really change. IOPS is an interesting number to compute, but real-world database performance isn't linearly correlated with it. Maybe if your workload consists mainly of random, uncached index scans system performance will scale just like IOPS, but that's pretty uncommon. [Rant about making sure not to drink the storage vendor IOPS Kool-Aid deleted] -- Greg Smith 2ndQuadrant US Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.us