Re: Inconsistant query plan
От | Alessandro Baretta |
---|---|
Тема | Re: Inconsistant query plan |
Дата | |
Msg-id | 43D73F68.3040306@barettadeit.com обсуждение исходный текст |
Ответ на | Re: Inconsistant query plan ("Daniel Gish" <dan@centrifugesolutions.com>) |
Список | 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/>
В списке pgsql-performance по дате отправления: