Re: [PERFORM] Optimizer Selecting Incorrect Index

2004-08-26 Thread David Price
3:08 PM To: Richard Huxton Cc: David Price; [EMAIL PROTECTED] Subject: Re: [PERFORM] Optimizer Selecting Incorrect Index Richard Huxton <[EMAIL PROTECTED]> writes: > Things to check: > 1. postgresql.conf settings match - different costs could cause this > 2. statistics on t

Re: [PERFORM] Optimizer Selecting Incorrect Index

2004-08-26 Thread Richard Huxton
Dennis Bjorklund wrote: On Wed, 25 Aug 2004, Richard Huxton wrote: These queries are different. The first returns 687 rows and the second 713 rows. The 687 and 713 are the number of rows in the plan, not the number of rows the queries return. D'OH! Thanks Dennis -- Richard Huxton Archonet Lt

Re: [PERFORM] Optimizer Selecting Incorrect Index

2004-08-25 Thread Dennis Bjorklund
On Wed, 25 Aug 2004, Richard Huxton wrote: > > Index Scan using trptserc on trans (cost=0.00..465.10 rows=44 width=118) > >Index Cond: (trn_patno = 19) > >Filter: ((trn_old_date >= '1994-08-23'::date) AND (trn_old_date <= > > '2004-08-23'::date) AND (trn_bill_inc = 'B'::bpchar)) > >

Re: [PERFORM] Optimizer Selecting Incorrect Index

2004-08-25 Thread Tom Lane
Richard Huxton <[EMAIL PROTECTED]> writes: > Things to check: > 1. postgresql.conf settings match - different costs could cause this > 2. statistics on the two columns (trn_patno,trn_old_date) - if they > differ considerably between systems that would also explain it. The different estimated row

Re: [PERFORM] Optimizer Selecting Incorrect Index

2004-08-25 Thread Richard Huxton
David Price wrote: I have 2 servers both with the exact same data, the same O.S., the same version of Postgres (7.4.5) and the exact same db schema's (one production server, one development server). One server is using the correct index for SQL queries resulting in extremely slow performance, the

[PERFORM] Optimizer Selecting Incorrect Index

2004-08-25 Thread David Price
I have 2 servers both with the exact same data, the same O.S., the same version of Postgres (7.4.5) and the exact same db schema's (one production server, one development server). One server is using the correct index for SQL queries resulting in extremely slow performance, the other server is pro