Re: Performance issue 6.5 versus 7.0

* Herbert Liechti <Herbert(dot)Liechti(at)thinx(dot)ch> [000526 14:32] wrote:
> Bryan White wrote:
> >
> > > Is there a way to force 7.0 using the defined indexes? Thanks
> > > for your help.
> >
> > Try set enable_seqscan=off before issuing your query.
>
> A little bit better (3 sec instead of 5 seconds). But fare away
> from the performance of 6.5.3. The explain now looks like this:
>
> EXPLAIN
> SELECT MailingListe_Id, MailingStatus, AbschlussDatum, Anschrift.Anzeige,
> Anschrift.Postfach, Anschrift.Strasse, Anschrift.Plz, Anschrift.Ort,
> Anschrift.TelDirekt, Person.Person_Id, Person.Name, Person.Vorname,
> Person.Anzeige
> FROM Anschrift, Person, MailingListe
> WHERE Person.Person_Id = MailingListe.Person_Id
> AND Anschrift.Anschrift_Id = MailingListe.Anschrift_Id
> AND MailingListe_Id = 2104;
>
> NOTICE: QUERY PLAN:
> Merge Join (cost=3717.38..7842.55 rows=1988449 width=136)
> -> Sort (cost=3717.38..3717.38 rows=8268 width=96)
> -> Merge Join (cost=44.73..2941.79 rows=8268 width=96)
> -> Index Scan using anschrift_id_ix on anschrift (cost=0.00..2725.55 rows=13661 width=76)
> -> Sort (cost=44.73..44.73 rows=61 width=20)
> -> Index Scan using mailingliste_id_ix on mailingliste (cost=0.00..42.94 rows=61 width=20)
> -> Index Scan using person_id_ix on person (cost=0.00..3721.19 rows=24051 width=40)
>
>
> An other advice?

Not really, try a "vacuum analyze tablename;" but otherwise i've hit
upon this regression in 7.0 as well :(

-Alfred