Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id 889CF632D5E for ; Thu, 29 Jul 2010 11:46:17 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia, port 10024) with ESMTP id 89793-04 for ; Thu, 29 Jul 2010 14:46:05 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from vms173003pub.verizon.net (vms173003pub.verizon.net [206.46.173.3]) by mail.postgresql.org (Postfix) with ESMTP id DD97663242F for ; Thu, 29 Jul 2010 11:46:06 -0300 (ADT) Received: from osgiliath.mathom.us ([unknown] [72.83.250.219]) by vms173003.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0L6B00AD2QBZ99C0@vms173003.mailsrvcs.net> for pgsql-performance@postgresql.org; Thu, 29 Jul 2010 09:45:42 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by osgiliath.mathom.us (Postfix) with ESMTP id 2550E6E667 for ; Thu, 29 Jul 2010 10:45:35 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at mathom.us 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 13mScUMQ-enI for ; Thu, 29 Jul 2010 10:45:34 -0400 (EDT) Received: by osgiliath.mathom.us (Postfix, from userid 1000) id DD1571FADF; Thu, 29 Jul 2010 10:45:34 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mathom.us; s=mail; t=1280414734; bh=NNLFPikvXtbsA2dmPpKSQ7GxYJYqHUPTLiml3S113II=; h=Date:From:To:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=u/ItjF7iripIj+TEVGZCETzM15jgrW/Zoegzu5 Ss8UiioxUhnL+yk3J0PkyjGrF8SWfW2QIo+UkM+t3r5i7z2TiFnFxTrbCsBkeqM6Bku s9rW2cLvhApQEAtXjQpb18vfoo82lxVhIujqrcsBLdt/htw/ZlhcA/UYNjPFEz3ggk= Date: Thu, 29 Jul 2010 10:45:34 -0400 From: Michael Stone To: pgsql-performance@postgresql.org Subject: Re: Testing Sandforce SSD Message-id: <54cd1c80-9b1f-11df-9b6a-001cc0cda50c@msgid.mathom.us> Mail-followup-to: pgsql-performance@postgresql.org References: <4C4C83DF.3010703@gmail.com> <4C4C8CCC.7080406@gmail.com> <4C4D6396.5020707@gmail.com> <4C4DAAE8.3060501@2ndquadrant.com> <4C4DE50B.1060102@gmail.com> <4C4DE5C9.8090004@2ndquadrant.com> <4C503473.5080105@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-disposition: inline In-reply-to: <4C503473.5080105@gmail.com> X-Pgp-Fingerprint: 02D5 315F F11F 1861 860E 1E02 F61A ACDC FA11 FFDE User-Agent: Mutt/1.5.20 (2009-06-14) 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: 201007/446 X-Sequence-Number: 39835 On Wed, Jul 28, 2010 at 03:45:23PM +0200, Yeb Havinga wrote: >Due to the LBA remapping of the SSD, I'm not sure of putting files >that are sequentially written in a different partition (together with >e.g. tables) would make a difference: in the end the SSD will have a >set new blocks in it's buffer and somehow arrange them into sets of >128KB of 256KB writes for the flash chips. See also >http://www.anandtech.com/show/2899/2 It's not a question of the hardware side, it's the software. The xlog needs to by synchronized, and the things the filesystem has to do to make that happen penalize the non-xlog disk activity. That's why my preferred config is xlog on ext2, rest on xfs. That allows the synchronous activity to happen with minimal overhead, while the parts that benefit from having more data in flight can do that freely. Mike Stone