RE : RE : RE : BUG #3519: Postgres takes the wrong query plan resulting in performance issues
От | Mouhamadou Dia |
---|---|
Тема | RE : RE : RE : BUG #3519: Postgres takes the wrong query plan resulting in performance issues |
Дата | |
Msg-id | BB6605E56C79CB4FA6CA491B706FBB210112E0@cpt127.magrit.int обсуждение исходный текст |
Ответ на | Re: RE : RE : BUG #3519: Postgres takes the wrong query plan resulting in performance issues (Heikki Linnakangas <heikki@enterprisedb.com>) |
Список | pgsql-bugs |
I've played with both parameters but it doesn't help in this case Thanks -----Message d'origine----- De=A0: Heikki Linnakangas [mailto:hlinnaka@gmail.com] De la part de Heikki = Linnakangas Envoy=E9=A0: 6 ao=FBt 2007 16:58 =C0=A0: Mouhamadou Dia Cc=A0: pgsql-bugs@postgresql.org Objet=A0: Re: RE : RE : [BUGS] BUG #3519: Postgres takes the wrong query pl= an resulting in performance issues Hmm. I don't see anything terribly wrong in the planner's estimates. The only estimate that's off is the # of rows in pror_org matching the qual orgt_cd =3D 'CHAIN', 27 estimated vs 1 actual. You could try increasing the statistics target for that column to get that estimate right. That might tip the planner to choose a plan with nested loop joins instead of hash joins. Have you played with enable_seqscan=3Doff or enable_hashjoin=3Doff? That's not a good long term solution, but it would be interesting to see what happens. Mouhamadou Dia wrote: > Sorry, > This output is coming from PG 8.1.19 > I'm attaching the one that is coming from 8.2.4 > Thanks and sorry for the confusion >=20 >=20 > -----Message d'origine----- > De : Heikki Linnakangas [mailto:hlinnaka@gmail.com] De la part de Heikki = Linnakangas > Envoy=E9 : 6 ao=FBt 2007 15:32 > =C0 : Mouhamadou Dia > Cc : pgsql-bugs@postgresql.org > Objet : Re: RE : [BUGS] BUG #3519: Postgres takes the wrong query plan re= sulting in performance issues >=20 > Mouhamadou Dia wrote: >> I'm sending in attachment the output of the explain analyze command and = the create table statements of tables involved in the query. >=20 > Wait, you said that the query takes 20 seconds on 8.2, but the explain > analyze output says that it actually took 50 seconds. Is this the output > from 8.2.4? >=20 --=20 Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-bugs по дате отправления: