Thank you for the response.
We run VACUUM ANALYZE every night, so we don't think this is a problem.
Postgres was also installed the same ways for both and we fine-tuned
some of the variables in the config files (regarding memory, for example).
Thank you.
Afra
Neil Conway wrote:
> Afra writes:
>
> >The postgres version for each box is 7.2.1.
>
>
> Upgrading to 7.2.3 would be a good idea (it won't effect this problem,
> it's just a good idea in general).
>
>
> >These are the EXPLAIN results on DB1:
> >
> >NOTICE: QUERY PLAN:
> >
> >Merge Join (cost=152183.00..271426.66 rows=9416137 width=105)
> > -> Sort (cost=141295.60..141295.60 rows=613709 width=69)
> > -> Seq Scan on ord_contact_name (cost=0.00..18568.09
> >rows=613709 width=69)
> > -> Sort (cost=10887.40..10887.40 rows=3069 width=36)
> > -> Index Scan using dv_job_number_ord_dv_job_num_ke on
> >ord_dv_job_num (cost=0.00..10709.67 rows=3069 width=36)
> >
> >And the EXPLAIN results on DB2:
> >
> >NOTICE: QUERY PLAN:
> >
> >Nested Loop (cost=0.00..9.91 rows=1 width=90)
> > -> Index Scan using dv_job_number_ord_dv_job_num_ke on
> >ord_dv_job_num (cost=0.00..3.89 rows=1 width=40)
> > -> Index Scan using ord_obj_guid_ord_contact_name_k on
> >ord_contact_name (cost=0.00..6.01 rows=1 width=50)
>
>
> Have you run VACUUM ANALYZE on both databases recently? (if you
> haven't, do so). The statistics for DB1 look bizarrely incorrect, so
> I'd suspect that updating them will fix the problem.
>
> Is PostgreSQL configured in the same way on both systems?
>
> Cheers,
>
> Neil
>
