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 AB65BD98F9;
	Tue, 27 Sep 2005 13:15:18 -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 52418-06; Tue, 27 Sep 2005 16:15:13 +0000 (GMT)
Received: from davinci.ethosmedia.com (server227.ethosmedia.com
	[209.128.84.227])
	by svr1.postgresql.org (Postfix) with ESMTP id 68720D98DB;
	Tue, 27 Sep 2005 13:15:12 -0300 (ADT)
X-EthosMedia-Virus-Scanned: no infections found
Received: from [63.195.55.98] (HELO [192.168.0.37])
	by davinci.ethosmedia.com (CommuniGate Pro SMTP 4.1.8)
	with ESMTP id 8161407; Tue, 27 Sep 2005 09:17:35 -0700
Message-ID: <4339700A.2030803@agliodbs.com>
Date: Tue, 27 Sep 2005 09:15:06 -0700
From: Josh Berkus <josh@agliodbs.com>
User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ron Peacetree <rjpeace@earthlink.net>
Cc: Dann Corbit <DCorbit@connx.com>, pgsql-hackers@postgresql.org,
	pgsql-performance@postgresql.org
Subject: Re: [PERFORM] A Better External Sort?
References: 
 <19483839.1127783447942.JavaMail.root@elwamui-polski.atl.sa.earthlink.net>
In-Reply-To: 
 <19483839.1127783447942.JavaMail.root@elwamui-polski.atl.sa.earthlink.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at hub.org
X-Spam-Status: No, hits=0 required=5 tests=[none]
X-Spam-Level: 
X-Archive-Number: 200509/1240
X-Sequence-Number: 73637

Ron,

I've somehow missed part of this thread, which is a shame since this is 
an area of primary concern for me.

Your suggested algorithm seems to be designed to relieve I/O load by 
making more use of the CPU.   (if I followed it correctly).  However, 
that's not PostgreSQL's problem; currently for us external sort is a 
*CPU-bound* operation, half of which is value comparisons.  (oprofiles 
available if anyone cares)

So we need to look, instead, at algorithms which make better use of 
work_mem to lower CPU activity, possibly even at the expense of I/O.

--Josh Berkus