X-Original-To: pgsql-performance-postgresql.org@postgresql.org Received: from localhost (wm.hub.org [200.46.204.128]) by postgresql.org (Postfix) with ESMTP id DAF5E9FA48B; Sun, 23 Jul 2006 22:29:49 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.128]) (amavisd-new, port 10024) with ESMTP id 28727-07; Mon, 24 Jul 2006 01:29:41 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey- X-Greylist: from auto-whitelisted by SQLgrey- Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id E46249FB1BE; Sun, 23 Jul 2006 22:29:40 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.6/8.13.6) with ESMTP id k6O1Tdln029921; Sun, 23 Jul 2006 21:29:39 -0400 (EDT) To: Robert Lor cc: Tatsuo Ishii , pgsql-hackers@postgresql.org, pgsql-performance@postgresql.org Subject: Re: Sun Donated a Sun Fire T2000 to the PostgreSQL In-reply-to: <44C419BC.1050503@sun.com> References: <20060617.101521.95879771.t-ishii@sraoss.co.jp> <10226.1150511655@sss.pgh.pa.us> <20060617.111838.39487910.t-ishii@sraoss.co.jp> <20060713.180234.45872055.t-ishii@sraoss.co.jp> <8669.1153422118@sss.pgh.pa.us> <44C088C8.9050303@sun.com> <21889.1153489365@sss.pgh.pa.us> <44C195F8.9010409@sun.com> <3706.1153678226@sss.pgh.pa.us> <44C419BC.1050503@sun.com> Comments: In-reply-to Robert Lor message dated "Sun, 23 Jul 2006 17:52:12 -0700" Date: Sun, 23 Jul 2006 21:29:39 -0400 Message-ID: <29920.1153704579@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200607/231 X-Sequence-Number: 20091 Robert Lor writes: > Tom Lane wrote: >> Yeah, those seem plausible, although the hold time for >> CheckpointStartLock seems awfully high --- about 20 msec >> per transaction. Are you using a nonzero commit_delay? >> > I didn't change commit_delay which defaults to zero. Hmmm ... AFAICS this must mean that flushing the WAL data to disk at transaction commit time takes (most of) 20 msec on your hardware. Which still seems high --- on most modern disks that'd be at least two disk revolutions, maybe more. What's the disk hardware you're testing on, particularly its RPM spec? regards, tom lane