X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id C2F31D9C3D; Thu, 29 Sep 2005 14:18:26 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 97225-03; Thu, 29 Sep 2005 17:18:23 +0000 (GMT) Received: from fetter.org (dsl092-188-065.sfo1.dsl.speakeasy.net [66.92.188.65]) by svr1.postgresql.org (Postfix) with ESMTP id C9834D9C65; Thu, 29 Sep 2005 14:18:23 -0300 (ADT) Received: from fetter.org (localhost.localdomain [127.0.0.1]) by fetter.org (8.13.4/8.12.10) with ESMTP id j8THHvJL004010; Thu, 29 Sep 2005 10:17:57 -0700 Received: (from shackle@localhost) by fetter.org (8.13.4/8.13.4/Submit) id j8THHv65004009; Thu, 29 Sep 2005 10:17:57 -0700 Date: Thu, 29 Sep 2005 10:17:57 -0700 From: David Fetter To: Luke Lonergan Cc: Josh Berkus , "Jeffrey W. Baker" , Ron Peacetree , pgsql-hackers@postgresql.org, pgsql-performance@postgresql.org Subject: Re: [PERFORM] A Better External Sort? Message-ID: <20050929171757.GC7534@fetter.org> References: <433C1C2D.7090908@agliodbs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.06 required=5 tests=[AWL=0.010, FORGED_RCVD_HELO=0.05] X-Spam-Level: X-Archive-Number: 200509/1380 X-Sequence-Number: 73777 On Thu, Sep 29, 2005 at 10:06:52AM -0700, Luke Lonergan wrote: > Josh, > > On 9/29/05 9:54 AM, "Josh Berkus" wrote: > > > Following an index creation, we see that 95% of the time required > > is the external sort, which averages 2mb/s. This is with seperate > > drives for the WAL, the pg_tmp, the table and the index. I've > > confirmed that increasing work_mem beyond a small minimum (around > > 128mb) had no benefit on the overall index creation speed. > > Yuuuup! That about sums it up - regardless of taking 1 or 2 passes > through the heap being sorted, 1.5 - 2 MB/s is the wrong number. > This is not necessarily an algorithmic problem, but is a > optimization problem with Postgres that must be fixed before it can > be competitive. > > We read/write to/from disk at 240MB/s and so 2 passes would run at a > net rate of 120MB/s through the sort set if it were that efficient. > > Anyone interested in tackling the real performance issue? (flame > bait, but for a worthy cause :-) I'm not sure that it's flamebait, but what do I know? Apart from the nasty number (1.5-2 MB/s), what other observations do you have to hand? Any ideas about what things are not performing here? Parts of the code that could bear extra scrutiny? Ideas on how to fix same in a cross-platform way? Cheers, D -- David Fetter david@fetter.org http://fetter.org/ phone: +1 510 893 6100 mobile: +1 415 235 3778 Remember to vote!