Re: Optimizing this count query - Mailing list pgsql-performance

From Tom Lane
Subject Re: Optimizing this count query
Date
Msg-id 3851.1105984549@sss.pgh.pa.us
Whole thread Raw
In response to Optimizing this count query  ("Andrei Bintintan" <klodoma@ar-sd.net>)
List 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 by date:

Previous
From: Kaloyan Iliev Iliev
Date:
Subject: Re: Performance problem from migrating between versions!
Next
From: Adrian Holovaty
Date:
Subject: Re: Index on a function and SELECT DISTINCT