Josh Berkus <[EMAIL PROTECTED]> writes:
> Back in the 7.0 days,
> WHERE EXISTS (SELECT * FROM a WHERE condition)
> was significantly slower on broad tables than
> WHERE EXISTS (SELECT small_col FROM a WHERE condition)
> Is this still true, or something that's been fixed in the last 3 versions?
It's still true that all the sub-select's output columns will be
evaluated. Given that this happens for at most one row, I'm not sure
how significant the hit really is. But it's annoying, seeing that the
outer EXISTS doesn't care what the column values are.
> Joe Celko is making fun of me because Oracle doesn't have this performance
> issue.
Perhaps Joe can tell us exactly which part of SQL92 says it's okay not
to evaluate side-effect-producing functions in the targetlist of an
EXISTS subselect.
I would like to make the system change the targetlist to just "SELECT 1"
in an EXISTS subquery. But I'm slightly concerned about changing the
semantics of existing queries. If someone can produce proof that this
is allowed (or even better, required) by the SQL spec, it'd be easier...
regards, tom lane
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
