RE : RE : RE : BUG #3519: Postgres takes the wrong query plan resulting in performance issues - Mailing list pgsql-bugs

From Mouhamadou Dia
Subject RE : RE : RE : BUG #3519: Postgres takes the wrong query plan resulting in performance issues
Date
Msg-id BB6605E56C79CB4FA6CA491B706FBB210112E1@cpt127.magrit.int
Whole thread Raw
In response to Re: RE : RE : BUG #3519: Postgres takes the wrong query plan resulting in performance issues  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
Thanks Tom,
By setting from_collapse_limit to more than 10, the query takes 133ms inste=
ad of 20s.
My question is: why even if from_collapse_limit is set to 8 (it's default v=
alue), the same query takes 30ms just by changing the order of PRPT_PRT and=
 PROR_ORG tables in the query?


-----Message d'origine-----
De=A0: Tom Lane [mailto:tgl@sss.pgh.pa.us]=20
Envoy=E9=A0: 6 ao=FBt 2007 21:31
=C0=A0: Gregory Stark
Cc=A0: Heikki Linnakangas; Mouhamadou Dia; pgsql-bugs@postgresql.org
Objet=A0: Re: RE : RE : [BUGS] BUG #3519: Postgres takes the wrong query pl=
an resulting in performance issues=20

Gregory Stark <stark@enterprisedb.com> writes:
> The structure of your query is a whole series of left outer joins, the re=
sult
> of which is then (inner) joined with one more table. The outer joins retu=
rn a
> whole lot of records but the inner join is only going to match a few of t=
hem.

Hmmm ... actually I see 6 tables inside the join-tree and four more
loose in the FROM-clause, ten relations altogether.  Which means the OP
is falling foul of from_collapse_limit, and it's not investigating every
possible join order.  Try setting from_collapse_limit to more than 10.

            regards, tom lane

pgsql-bugs by date:

Previous
From: "Brodie Thiesfield"
Date:
Subject: Re: BUG #3520: insert causing error "invalid memory alloc request size 2147483648"
Next
From: "Lamia Jackson"
Date:
Subject: BUG #3514: buggy install + no manual support (add)