Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-performance by date

Next:From: Merlin MoncureDate: 2010-04-24 13:23:40
Subject: Re: Replacing Cursors with Temporary Tables
Previous:From: Eliot GableDate: 2010-04-24 02:31:16
Subject: Re: Replacing Cursors with Temporary Tables

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group