Re: Replacing Cursors with Temporary Tables

From: "Pierre C" <lists(at)peufeu(dot)com>
To: "Eliot Gable" <egable+pgsql-performance(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Replacing Cursors with Temporary Tables
Date: 2010-04-24 09:26:58
Message-ID: op.vbntu8w9eorkce@immo.peufeu.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance


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...

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Merlin Moncure 2010-04-24 13:23:40 Re: Replacing Cursors with Temporary Tables
Previous Message Eliot Gable 2010-04-24 02:31:16 Re: Replacing Cursors with Temporary Tables