Re: How to optimize a query...
От | Tom Lane |
---|---|
Тема | Re: How to optimize a query... |
Дата | |
Msg-id | 17563.921079651@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | How to optimize a query... (secret <secret@kearneydev.com>) |
Список | pgsql-sql |
> I originally had this query with an OR clause instead of the UNION, > which made it amazingly impossibly slow, with the UNION it's far faster > however it's still very slow,(10,000+ rows in both stables), is there a > way to speed this up? Hmm. What does EXPLAIN give as the query plan if you use the OR approach? The UNION method requires much more work than a decent OR plan would need; as you can see from the query plan, it has to sort and unique-ify the results of the two sub-selects in order to discard duplicate tuples. If you don't mind seeing the same tuple twice when it matches on both PO fields, you could use UNION ALL rather than UNION to avoid the sort step. But that's just a hack... I think the problem might be that Postgres doesn't know how to handle ORed join clauses very efficiently. Something to work on in the future. > I have another query that joins the result of this with 5 other > tables, unfortunately that one takes like 10 minutes... How long does it take to EXPLAIN that query? Postgres' optimizer has some bugs that cause it to take an unreasonable amount of time to plan a query that joins more than a few tables. You can tell whether it's the planning or execution time that's the problem by comparing EXPLAIN runtime to the actual query. (The bugs are fixed in 6.5, btw. In the meantime a workaround is to reduce the GEQO threshold to less than the number of tables in the query that's giving you trouble.) regards, tom lane
В списке pgsql-sql по дате отправления: