From: | Alessandro Baretta <a(dot)baretta(at)barettadeit(dot)com> |
---|---|
To: | Daniel Gish <dan(at)centrifugesolutions(dot)com> |
Cc: | Michael Fuhr <mike(at)fuhr(dot)org>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Inconsistant query plan |
Date: | 2006-01-25 09:05:44 |
Message-ID: | 43D73F68.3040306@barettadeit.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
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/>
From | Date | Subject | |
---|---|---|---|
Next Message | Evgeny Gridasov | 2006-01-25 12:01:34 | DB responce during DB dump |
Previous Message | Daniel Gish | 2006-01-25 01:04:10 | Re: Inconsistant query plan |