Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Slow SELECT .. IN (singelton SELECT..) ? 1

Status
Not open for further replies.

exys

Programmer
Jan 22, 2004
4
US
I would think the following two queries should be processed the same, but the first one takes over a second, while the second takes a few milliseconds.

SELECT * FROM tblData WHERE idA IN (SELECT idB FROM tblIndex WHERE idC=1234);

SELECT * FROM tblData WHERE idA = (SELECT idB FROM tblIndex WHERE idC=1234);

idA is primary key and unique.
idB is foreign key ref. idA.
idC is primary key and unique.

tblData has about 30000 records, tblIndex has about 5000 records..

The (SELECT idB...) always returns a singleton since idC is primary key, so they should be the same, right?

Why does IN take so long ?
Running IB 6.0.2.0 on Win2000.

All ideas much appreciated.
</Anders>
 
That's because IB6 will run the subselect once for each row in table tblData to verify the IN clause, but (I believe) only once to verify the = clause.

It is a problem with the optimizer.
 
Thanks for the reply.

After a lot of testing and searching I started to suspect that it had something to do with the optimizer like you say, and I even tried the same thing under the latest Firebird release (1.5) with the same result.

Today I found out that the issue is logged in the Firebird Sourceforge bugtrack system, but there are no comments or solutions..
The workaround presented in the description did not work though.
It's logged with low priority but to me it's a pretty major flaw... :(

I've tried to work around it with a PLAN, but haven't figured out how yet - I'd appreciate any hits ;)

</A>
 
The = version works for this particular query, but I have other queries where the sub-SELECT returns more than one result.
For those cases I haven't found a workaround yet.

Tried it on MSSQL - apparently that optimizer does the right thing.
Does anyone know if this is fixed in the commercial version of Interbase (7.1)?
 
I thought it was fixed in FB1.5... I don't know about Interbase 7.x.

If you show us your queries, we can help reformulate them... Here is one way that could help:

Code:
SELECT D.* FROM tblData D
INNER JOIN tblIndex I
ON D.idA = I.idB
AND I.idC = 1234;
 
That worked perfectly !
Thanks a bunch !

Even with &quot;...AND I.idC IN (1234,1235,1236)&quot; it works as fast as you would expect.

Thanks again for a good workaround !
</A>
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top