Re: [SQL] Query optimizing - paradox behave

2001-07-20 Thread Tom Lane
"David M. Richter" <[EMAIL PROTECTED]> writes: > The query with the 3 tables is faster than the query with 2 tables. How you figure that? > time psql -d compare -c "SELECT patient.*,study.* FROM > patient,study,relpatient_study000 r0 WHERE > (patient.chiliOID=r0.parentOID AND study.chiliOID=r0.

[SQL] Query optimizing - paradox behave

2001-07-20 Thread David M. Richter
(Here again; my email adress was killed) Hallo ! I want to tune a database. There a many redundant datas in the database , because of all the relations were consider as n:m relations. But the most of them are 1:n Relations. So my approach was to cut the redundancies to get more performance. But

Re: [SQL] Query optimizing - paradox behave

2001-07-19 Thread Josh Berkus
David, You will no doubt hear later from the tuning experts on the list. However, let me save everybody some time by verifying some basics: 1. When you restructured the database, you ran VACUUM ANALYZE on the new database (pacs)? 2. You said that you "eliminated the indexes" because they weren'

Re: [SQL] Query optimizing - paradox behave

2001-07-19 Thread Stephan Szabo
What version are you using? (dbPG95GetIndex?) On Thu, 19 Jul 2001, David M. Richter wrote: > Hallo ! > > I want to tune a database. There a many redundant datas in the database > , because of all the relations were consider as n:m relations. But the > most of them are 1:n Relations. So my appr

[SQL] Query optimizing - paradox behave

2001-07-19 Thread David M. Richter
Hallo ! I want to tune a database. There a many redundant datas in the database , because of all the relations were consider as n:m relations. But the most of them are 1:n Relations. So my approach was to cut the redundancies to get more performance. But .. happens! The query with the 3 tables i