Received: from maia.hub.org (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id C0601632D50 for ; Sat, 24 Apr 2010 06:27:13 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 58570-06 for ; Sat, 24 Apr 2010 09:27:03 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from 30.mail-out.ovh.net (30.mail-out.ovh.net [213.186.62.213]) by mail.postgresql.org (Postfix) with SMTP id EAD22632217 for ; Sat, 24 Apr 2010 06:27:02 -0300 (ADT) Received: (qmail 12646 invoked by uid 503); 24 Apr 2010 09:24:52 -0000 Received: from b9.ovh.net (HELO mail638.ha.ovh.net) (213.186.33.59) by 30.mail-out.ovh.net with SMTP; 24 Apr 2010 09:24:52 -0000 Received: from b0.ovh.net (HELO queueout) (213.186.33.50) by b0.ovh.net with SMTP; 24 Apr 2010 09:26:59 -0000 Received: from par69-8-88-161-102-87.fbx.proxad.net (HELO immo.peufeu.com) (lists%peufeu.com@88.161.102.87) by ns0.ovh.net with SMTP; 24 Apr 2010 09:26:58 -0000 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Eliot Gable" , pgsql-performance@postgresql.org Subject: Re: Replacing Cursors with Temporary Tables References: Date: Sat, 24 Apr 2010 11:26:58 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Pierre C" Message-ID: In-Reply-To: User-Agent: Opera Mail/10.10 (Linux) X-Ovh-Tracer-Id: 13358239446516041321 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=-0.001 tagged_above=-10 required=5 tests=BAYES_40=-0.001 X-Spam-Level: X-Archive-Number: 201004/310 X-Sequence-Number: 38560 FYI, I had a query like this : (complex search query ORDER BY foo LIMIT X) LEFT JOIN objects_categories oc LEFT JOIN categories c GROUP BY ... (more joins) ORDER BY foo LIMIT X Here, we do a search on "objects" (i'm not gonna give all the details, they're not interesting for the problem at hand). Point is that these objects can belong to several categories, so I need to perform a GROUP BY with array_agg() somewhere unless I want the JOIN to return several rows per object, which is not what I want. This makes the query quite complicated... I ended up rewriting it like this : (complex search query ORDER BY foo LIMIT X) LEFT JOIN (SELECT .. FROM objects_categories oc LEFT JOIN categories c GROUP BY ... ) ON ... (more joins) ORDER BY foo LIMIT X Basically moving the aggregates into a separate query. It is easier to handle. I tried to process it like this, in a stored proc : - do the (complex search query ORDER BY foo LIMIT X) alone and stuff it in a cursor - extract the elements needed into arrays (mostly object_id) - get the other information as separate queries like : SELECT object_id, category_id, category_name FROM objects_categories JOIN categories ON ... WHERE object_id =ANY( my_array ); and return the results into cursors, too. Or like this (using 2 cursors) : SELECT object_id, array_agg(category_id) FROM objects_categories WHERE object_id =ANY( my_array ); SELECT category_id, category_name, ... FROM categories WHERE category_id IN ( SELECT category_id FROM objects_categories WHERE object_id =ANY( my_array )); I found it to be quite faster, and it also simplifies my PHP code. From PHP's point of view, it is simpler to get a cursor that returns the objects, and separate cursors that can be used to build an in-memory PHP hashtable of only the categories we're going to display. Also, it avoids retrieving lots of data multiple times, since many objects will belong to the same categories. With the second example, I can use my ORM to instantiate only one copy of each. It would be quite useful if we could SELECT from a cursor, or JOIN a cursor to an existing table...