Re: Optimizing this count query
От | Tom Lane |
---|---|
Тема | Re: Optimizing this count query |
Дата | |
Msg-id | 3851.1105984549@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Optimizing this count query ("Andrei Bintintan" <klodoma@ar-sd.net>) |
Список | pgsql-performance |
"Andrei Bintintan" <klodoma@ar-sd.net> writes: > SELECT count(o.id) FROM orders o > INNER JOIN report r ON o.id=r.id_order > INNER JOIN status s ON o.id_status=s.id > INNER JOIN contact c ON o.id_ag=c.id > INNER JOIN endkunde e ON o.id_endkunde=e.id > INNER JOIN zufriden z ON r.id_zufriden=z.id > INNER JOIN plannung v ON v.id=o.id_plannung > INNER JOIN mpsworker w ON v.id_worker=w.id > INNER JOIN person p ON p.id = w.id_person > WHERE o.id_status>3 > I'm asking how can I improve the execution time of this query, because = > these tables are always increasing. And this count sometimes takes more = > than 10 secs and I need to run this count very offen. Unless you've increased the default value of join_collapse_limit, this construction will be forcing the join order; see http://www.postgresql.org/docs/7.4/static/explicit-joins.html I'm not sure if you can improve the join order at all --- since you only showed EXPLAIN and not EXPLAIN ANALYZE, it's hard to be sure whether any of the steps are producing large intermediate results. But it's something to look into. You should also ask yourself if you need to be joining so many tables at all. The planner seems to think that only the o/r join is really going to affect the result row count. I can't tell if it's right or not, but if this is a star schema and the other seven tables are just detail tables, you don't need them in order to obtain a count. regards, tom lane
В списке pgsql-performance по дате отправления: