X-Original-To: pgsql-performance-postgresql.org@postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id D2F4F9FB274 for ; Tue, 15 Aug 2006 14:25:49 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 55297-04 for ; Tue, 15 Aug 2006 14:25:38 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from vms048pub.verizon.net (vms048pub.verizon.net [206.46.252.48]) by postgresql.org (Postfix) with ESMTP id 812C79FB1FB for ; Tue, 15 Aug 2006 14:25:39 -0300 (ADT) Received: from osgiliath.mathom.us ([72.66.19.42]) by vms048.mailsrvcs.net (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPA id <0J4100HGPV2CY2O1@vms048.mailsrvcs.net> for pgsql-performance@postgresql.org; Tue, 15 Aug 2006 12:25:25 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by osgiliath.mathom.us (Postfix) with ESMTP id 529C96FBD1; Tue, 15 Aug 2006 13:25:22 -0400 (EDT) Received: from osgiliath.mathom.us ([127.0.0.1]) by localhost (osgiliath.home.mathom.us [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 2VvsESnmFF+U; Tue, 15 Aug 2006 13:25:21 -0400 (EDT) Received: by osgiliath.mathom.us (Postfix, from userid 1000) id 55A3D6FC68; Tue, 15 Aug 2006 13:25:21 -0400 (EDT) Date: Tue, 15 Aug 2006 13:25:21 -0400 From: Michael Stone Subject: Re: Postgresql Performance on an HP DL385 and In-reply-to: <20060815162524.GR27928@pervasive.com> To: "Jim C. Nasby" Cc: pgsql-performance@postgresql.org Mail-followup-to: "Jim C. Nasby" , pgsql-performance@postgresql.org Message-id: <20060815172519.GT2900@mathom.us> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-disposition: inline X-Virus-Scanned: Debian amavisd-new at mathom.us X-Pgp-Fingerprint: 53 FF 38 00 E7 DD 0A 9C 84 52 84 C5 EE DF 7C 88 References: <3E37B936B592014B978C4415F90D662D03FFEF6E@MI8NYCMAIL06.Mi8.com> <721b21dc0608082245u6ee62e7dg522ff18e4d72683@mail.gmail.com> <20060809210539.GR40481@pervasive.com> <1155180553.13315.0.camel@amd64-gentoo-laptop> <20060810110935.GF2900@mathom.us> <20060814153841.GF27928@pervasive.com> <20060814170338.GM2900@mathom.us> <20060815162524.GR27928@pervasive.com> User-Agent: Mutt/1.5.12-2006-07-14 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.796 tagged_above=0 required=5 tests=AWL, FORGED_RCVD_HELO, SPF_PASS X-Spam-Level: X-Archive-Number: 200608/230 X-Sequence-Number: 20415 On Tue, Aug 15, 2006 at 11:25:24AM -0500, Jim C. Nasby wrote: >Well, if the controller is caching with a BBU, I'm not sure that order >matters anymore, because the controller should be able to re-order at >will. Theoretically. :) But this is why having some actual data posted >somewhere would be great. You're missing the point. It's not a question of what happens once it gets to the disk/controller, it's a question of whether the xlog write has to compete with some other write activity before the write gets to the disk (e.g., at the filesystem level). If you've got a bunch of stuff in a write buffer on the OS level and you try to push the xlog write out, you may have to wait for the other stuff to get to the controller write cache before the xlog does. It doesn't matter if you don't have to wait for the write to get from the controller cache to the disk if you already had to wait to get to the controller cache. The effect is a *lot* smaller than not having a non-volatile cache, but it is an improvement. (Also, the difference between ext2 and xfs for the xlog is pretty big itself, and a good reason all by itself to put xlog on a seperate partition that's small enough to not need journalling.) Mike Stone