views:

145

answers:

3

I am using GridSQL where I get some performance problems whenever the SQL pattern INNER JOIN (SELECT arises. I am therefore considering rewriting all these queries into two queries, one creating a temporary table using the exact select statement and the other query joining with the temporary table, so the pattern would be INNER JOIN temp_table (...) instead.

In which cases would this not work? As you might suspect, I am hoping for no answers to this question. ;)

+1  A: 

The only time a sub-select can't easily be broken off into a temp-table is when it references fields in the outer table.

For "... INNER JOIN (SELECT ..." I doubt you would have that issue (or if it's even possible, I don't recall ever trying it), since you should only be referring to fields from the first table in the join criteria.

Timothy Walters
+1  A: 

I don't think a temp table will speed up your queries! Instead you should optimize your queries. Things you can do:

  • Filter the records before inner joining them with other record sets
  • Define proper indexes

-Pavel

Pavel Nikolov
It is possible that the query optimiser for the SQL is doing the steps that you want to do manually so you won't see a speed up
Mark
Query optimizer does a lot of work for you, but I'm sure it can't optimize every query... And it's considered a good idea to filter all the sets before joining them instead of first joining large amount of records and then filtering them! What is more the SQL query optimizer will not create indexes for you!
Pavel Nikolov
I agree with you if you talk about MySQL, PostgreSQL or anything like them, though GridSQL is a special case where you have several nodes and the query planner is not as mature as for the two mentioned. I know the performance effect of doing this (which is from 10-20 minutes per query to less then thirty seconds).
David
A: 

In which cases can INNER JOIN (SELECT … not be rewritten using temp table

if the query you are replacing with a temp table can result in a huge result set, I would avoid using a temp table. The overhead generating it would negate any possible gain.

KM