Received: from localhost (maia-1.hub.org [200.46.204.191]) by postgresql.org (Postfix) with ESMTP id A83E89FBDB0 for ; Tue, 10 Jul 2007 12:25:34 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.191]) (amavisd-maia, port 10024) with ESMTP id 30895-07-2 for ; Tue, 10 Jul 2007 12:25:30 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from westnet.com (westnet.com [216.187.52.2]) by postgresql.org (Postfix) with ESMTP id F3B429FB8B0 for ; Tue, 10 Jul 2007 12:25:29 -0300 (ADT) Received: from westnet.com (localhost [127.0.0.1]) by westnet.com (8.14.0/8.14.0) with ESMTP id l6AFPUBp016038 for ; Tue, 10 Jul 2007 11:25:30 -0400 (EDT) Received: from localhost (gsmith@localhost) by westnet.com (8.14.0/8.13.2/Submit) with ESMTP id l6AFPUva016035 for ; Tue, 10 Jul 2007 11:25:30 -0400 (EDT) X-Authentication-Warning: westnet.com: gsmith owned process doing -bs Date: Tue, 10 Jul 2007 11:25:30 -0400 (EDT) From: Greg Smith X-X-Sender: gsmith@westnet.com To: PostgreSQL-patches Subject: Re: Maintaining cluster order on insert In-Reply-To: <19371.1184078079@sss.pgh.pa.us> Message-ID: References: <200705152223.l4FMNJa17969@momjian.us> <464A33AB.1050401@enterprisedb.com> <20070516003810.GI20707@nasby.net> <464B15EF.4000808@enterprisedb.com> <464D96D6.1030608@enterprisedb.com> <457.1184023772@sss.pgh.pa.us> <19371.1184078079@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200707/130 X-Sequence-Number: 3128 On Tue, 10 Jul 2007, Tom Lane wrote: > It's just desktop-grade junk :-(. Feel free to repeat the test on > something more serious. Right, but even such junk can be setup such that the disks honor commits, just wanted to confirm you didn't go out of your way to do that--sounds like you didn't. My mini-lab at home has two PG test systems, one with a real write cache, the other has an IDE drive with the cache turned off so commits actually wait to hit the platter. The painful slowness of writes in that situation keeps me grounded as to how much data integrity actually costs if you're not accelerating it, and the differences in benchmarks between the two systems (which are otherwise a similar class of hardware) can be informative. > Anyway the numbers seemed relatively consistent after the setup and > first test cycle, so I think the part I was actually trying to draw > conclusions from was probably real enough. Agreed, just figuring out the test ramp-up situation, and your explanation for that quirk sounds reasonable. -- * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD