Re: Performance issue 6.5 versus 7.0

* Herbert Liechti <Herbert.Liechti@thinx.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