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 7EFD0D9CAD; Fri, 30 Sep 2005 17:37:35 -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 83576-06; Fri, 30 Sep 2005 20:37:32 +0000 (GMT) Received: from davinci.ethosmedia.com (server227.ethosmedia.com [209.128.84.227]) by svr1.postgresql.org (Postfix) with ESMTP id E5033D9701; Fri, 30 Sep 2005 17:37:32 -0300 (ADT) X-EthosMedia-Virus-Scanned: no infections found Received: from [64.81.245.111] (account josh@agliodbs.com HELO temoku.sf.agliodbs.com) by davinci.ethosmedia.com (CommuniGate Pro SMTP 4.1.8) with ESMTP id 8180681; Fri, 30 Sep 2005 13:39:57 -0700 From: Josh Berkus Reply-To: josh@agliodbs.com Organization: Aglio Database Solutions To: Ron Peacetree Subject: Re: [PERFORM] A Better External Sort? Date: Fri, 30 Sep 2005 13:41:22 -0700 User-Agent: KMail/1.8 Cc: pgsql-hackers@postgresql.org, pgsql-performance@postgresql.org References: <31833713.1128111650174.JavaMail.root@elwamui-polski.atl.sa.earthlink.net> In-Reply-To: <31833713.1128111650174.JavaMail.root@elwamui-polski.atl.sa.earthlink.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200509301341.22795.josh@agliodbs.com> X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.046 required=5 tests=[AWL=-0.004, FORGED_RCVD_HELO=0.05] X-Spam-Level: X-Archive-Number: 200509/1424 X-Sequence-Number: 73821 Ron, > That 11MBps was your =bulk load= speed. If just loading a table > is this slow, then there are issues with basic physical IO, not just > IO during sort operations. Oh, yeah. Well, that's separate from sort. See multiple posts on this list from the GreenPlum team, the COPY patch for 8.1, etc. We've been concerned about I/O for a while. Realistically, you can't do better than about 25MB/s on a single-threaded I/O on current Linux machines, because your bottleneck isn't the actual disk I/O. It's CPU. Databases which "go faster" than this are all, to my knowledge, using multi-threaded disk I/O. (and I'd be thrilled to get a consistent 25mb/s on PostgreSQL, but that's another thread ... ) > As I said, the obvious candidates are inefficient physical layout > and/or flawed IO code. Yeah, that's what I thought too. But try sorting an 10GB table, and you'll see: disk I/O is practically idle, while CPU averages 90%+. We're CPU-bound, because sort is being really inefficient about something. I just don't know what yet. If we move that CPU-binding to a higher level of performance, then we can start looking at things like async I/O, O_Direct, pre-allocation etc. that will give us incremental improvements. But what we need now is a 5-10x improvement and that's somewhere in the algorithms or the code. -- --Josh Josh Berkus Aglio Database Solutions San Francisco