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 по дате отправления:

Предыдущее
От: Kaloyan Iliev Iliev
Дата:
Сообщение: Re: Performance problem from migrating between versions!
Следующее
От: Adrian Holovaty
Дата:
Сообщение: Re: Index on a function and SELECT DISTINCT