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 BB6605E56C79CB4FA6CA491B706FBB210112E0@cpt127.magrit.int
Whole thread Raw
In response to Re: RE : RE : BUG #3519: Postgres takes the wrong query plan resulting in performance issues  (Heikki Linnakangas <heikki@enterprisedb.com>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: Having trouble building 64-bit pgsql 7.4.17 on HPUX ia64
Next
From: "Brodie Thiesfield"
Date:
Subject: Re: BUG #3520: insert causing error "invalid memory alloc request size 2147483648"