Cost of using subquery vs using same table twice in query

Question

Hi all,
In a current project, I was asked by my supervisor what is the cost difference between the following two methods. First method is using a subquery to get the name field from table2. A subquery is needed because it requires the field sa_id from table1. The second method is using table2 again under a different alias to obtain table2.name. The two table2 are not self-joined. The outcome of these two queries are the same.
Using subquery:
select a.sa_id R1, b.other_field R2,
(select b.name from b
where b.b_id = a.sa_id) R3
from table1 a, table2 b
where ...Using same table twice (table2 under 2 different aliases)
select a.sa_id R1, b.other_field R2, c.name R3
from table1 a, table2 b, table2 c
where
c.b_id = a.sa_id,
and ....Can anyone tell me which version is better and why? (or under what circumstances, which version is better). And what are the costs involved? Many thanks.

Answer 1

pl/sql novice wrote:
Hi all,
In a current project, I was asked by my supervisor what is the cost difference between the following two methods. First method is using a subquery to get the name field from table2. A subquery is needed because it requires the field sa_id from table1. The second method is using table2 again under a different alias to obtain table2.name. The two table2 are not self-joined. The outcome of these two queries are the same.
Using subquery:
Using same table twice (table2 under 2 different aliases)
Can anyone tell me which version is better and why? (or under what circumstances, which version is better). And what are the costs involved? Many thanks.In theory, if you use the scalar "subquery" approach, the correlated subquery needs to be executed for each row of your result set. Depending on how efficient the subquery is performed this could require significant resources, since you have that recursive SQL that needs to be executed for each row.
The "join" approach needs to read the table only twice, may be it can even use an indexed access path. So in theory the join approach should perform better in most cases.
Now the Oracle runtime engine (since Version 8) introduces a feature called "filter optimization" that also applies to correlated scalar subqueries. Basically it works like an in-memory hash table that caches the (hashed) input values to the (deterministic) correlated subquery and the corresponding output values. The number of entries of the hash table is fixed until 9i (256 entries) whereas in 10g it is controlled by a internal parameter that determines the size of the table (and therefore can hold different number of entries depending on the size of each element).
If the input value of the next row corresponds to the input value of the previous row then this optimization returns immediately the corresponding output value without any further action. If the input value can be found in the hash table, the corresponding output value is returned, otherwise execute the query and keep the result combination and eventually attempt to store this new combination in the hash table, but if a hash collision occurs the combination will be discarded.
So the effectiveness of this clever optimization largely depends on three different factors: The order of the input values (because as long as the input value doesn't change the corresponding output value will be returned immediately without any further action required), the number of distinct input values and finally the rate of hash collisions that might occur when attempting to store a combination in the in-memory hash table.
In summary unfortunately you can't really tell how good this optimization is going to work at runtime and therefore can't be properly reflected in the execution plan.
You need to test both approaches individually because in the optimal case the optimization of the scalar subquery will be superior to the join approach, but it could also well be the other around, depending on the factors mentioned.
Regards,
Randolf
Oracle related stuff blog:
http://oracle-randolf.blogspot.com/
SQLTools++ for Oracle (Open source Oracle GUI for Windows):
http://www.sqltools-plusplus.org:7676/
http://sourceforge.net/projects/sqlt-pp/