Daniel Gish wrote:
> Hi,
> Thanks for your response. The actual query is below; the joins are only 4
> deep. Adjusting the stats target did help, but not dramatically.
>
> QUERY PLAN
> ----------------------------------------------------------------------------
> ----------------------------------------------------------------------------
> ---------------------------------------
> Nested Loop (cost=978.19..37161.81 rows=133 width=4) (actual
> time=2511.676..2511.676 rows=0 loops=1)
> -> Merge Join (cost=978.19..22854.00 rows=4244 width=4) (actual
> time=1718.420..2510.128 rows=92 loops=1)
> ...
> -> Nested Loop (cost=0.00..974.33 rows=113 width=8) (actual
time=0.078..2.305 rows=19 loops=1)
I have a similar problem recently. An importat diagnostic tool for these issues
is the pg_stats view. Let me suggest that you post the relevant lines from
pg_stats, so that with some help you will be able to discover what data advises
the query planner to overestimate the cardinality of some joins and
underestimate others.
Alex
--
*********************************************************************
http://www.barettadeit.com/
Baretta DE&IT
A division of Baretta SRL
tel. +39 02 370 111 55
fax. +39 02 370 111 54
Our technology:
The Application System/Xcaml (AS/Xcaml)
<http://www.asxcaml.org/>
The FreerP Project
<http://www.freerp.org/>