fleshyorgans

Potentially.

Example:
SELECT t.* FROM table t WHERE t.id IN (SELECT DISTINCT f.id FROM table f, table e WHERE f.something = e.somethingelse AND f.someotherthing = e.somethingdifferent)


In Postgres and MySQL, IN seems to be fairly efficient and treats the subselect as a simple list. In SQL Server, it appears that IN does some kind of massive join, or perhaps a series of SELECTs times the number of rows in the superselect’s table.

All I know is that code works fine with little latency under pgsql and mysql, but at a certain row limit SQL Server is an order of magnitude different — we’re talking 10 seconds for a select versus half a second. The solution is to not use IN — do a JOIN, instead.

Just thought I’d pass that on to all you DB peeps.

(And for the record, I like IN statements because they seem more semantic and readable to me.)