From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: subquery vs join on 7.4.5 |
Date: | 2005-02-23 16:54:52 |
Message-ID: | 20117.1109177692@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
David Haas <dave(at)modelpredictivesystems(dot)com> writes:
> I'm comparing the speeds of the following two queries on 7.4.5. I was
> curious why query 1 was faster than query 2:
> query 1:
> Select layer_number
> FROM batch_report_index
> WHERE device_id = (SELECT device_id FROM device_index WHERE device_name
> ='CP8M')
> AND technology_id = (SELECT technology_id FROM technology_index WHERE
> technology_name = 'G12');
> query 2:
> Select b.layer_number
> FROM batch_report_index b, device_index d, technology_index t
> WHERE b.device_id = d.device_id
> AND b.technology_id = t.technology_id
> AND d.device_name = 'CP8M'
> AND t.technology_name = 'G12';
Why didn't you try a two-column index on batch_report_index(device_id,
technology_id) ?
Whether this would actually be better than a seqscan I'm not sure, given
the large number of matching rows. But the planner would surely try it
given that it's drastically underestimating that number :-(
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | G u i d o B a r o s i o | 2005-02-23 17:50:16 | Re: Problem with 7.4.5 and webmin 1.8 in grant function |
Previous Message | Tom Lane | 2005-02-23 16:44:15 | Re: Inefficient Query Plans |