Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id 33D821337D75 for ; Wed, 11 May 2011 15:12:57 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia, port 10024) with ESMTP id 99719-02-2 for ; Wed, 11 May 2011 18:12:49 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from 26.mail-out.ovh.net (5.26.mail-out.ovh.net [46.105.57.162]) by mail.postgresql.org (Postfix) with SMTP id B231E1337CA1 for ; Wed, 11 May 2011 15:10:59 -0300 (ADT) Received: (qmail 12569 invoked by uid 503); 11 May 2011 17:37:27 -0000 Received: from b9.ovh.net (HELO mail620.ha.ovh.net) (213.186.33.59) by 26.mail-out.ovh.net with SMTP; 11 May 2011 17:37:27 -0000 Received: from b0.ovh.net (HELO queueout) (213.186.33.50) by b0.ovh.net with SMTP; 11 May 2011 20:12:48 +0200 Received: from par69-8-88-161-102-87.fbx.proxad.net (HELO apollo13) (lists%peufeu.com@88.161.102.87) by ns0.ovh.net with SMTP; 11 May 2011 20:12:47 +0200 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Scott Marlowe" , "Shaun Thomas" Cc: "Craig Ringer" , "Aren Cambre" , pgsql-performance@postgresql.org Subject: Re: Postgres refusing to use >1 core References: <4DC81A3F020000250003D433@gw.wicourts.gov> <4DC81D56020000250003D438@gw.wicourts.gov> <4DC8B893.3060908@postnewspapers.com.au> <4DC9E7C5.9080309@postnewspapers.com.au> <4DCAB3A1.2090507@peak6.com> Date: Wed, 11 May 2011 20:10:54 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Pierre C" Message-ID: In-Reply-To: <4DCAB3A1.2090507@peak6.com> User-Agent: Opera Mail/11.10 (Linux) X-Ovh-Tracer-Id: 15104791675359004362 X-Ovh-Remote: 88.161.102.87 (par69-8-88-161-102-87.fbx.proxad.net) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-Spam-Check: DONE|U 0.5/N X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.585 tagged_above=-10 required=5 tests=BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SARE_MILLIONSOF=0.315 X-Spam-Level: X-Archive-Number: 201105/156 X-Sequence-Number: 43665 > This is a problem I encounter constantly wherever I go. Programmer > selects millions of rows from giant table. Programmer loops through > results one by one doing some magic on them. Programmer submits queries > back to the database. Even in batches, that's going to take ages. Reminds me of a recent question on stackoverflow : http://stackoverflow.com/questions/5952020/how-to-optimize-painfully-slow-mysql-query-that-finds-correlations And the answer : http://stackoverflow.com/questions/5952020/how-to-optimize-painfully-slow-mysql-query-that-finds-correlations/5954041#5954041 OP was thinking "row-based", with subqueries in the role of "doing some magicm". Using a set-based solution with cascading WITH CTEs (and using the previous CTE as a source in the next one for aggregation) => 100x speedup !