Comments on: Filter Subqueries

By: Plan timing « Oracle Scratchpad

Plan timing « Oracle Scratchpad — Mon, 19 Nov 2012 21:59:26 +0000

[...] Note: although the plan in lines 3 – 7 could be executed once for each row returned by the plan in lines 9 – 11, the number of executions could (and in this case is) fewer than the worst case thanks to scalar subquery caching. [...]

By: Indexes are Tables – All Things Oracle

Indexes are Tables – All Things Oracle — Fri, 16 Dec 2011 14:48:17 +0000

[...] different products – which is unlikely in this case) we may find that our subquery benefits from “scalar subquery caching”, which means that under perfect conditions we will run the subquery just once per product sold in [...]

By: Victor

Victor — Fri, 03 Sep 2010 14:47:28 +0000

Thanks Jonathan for your reply. I see. I came to this post from “Join ordering” post where you talk about different strategies on similar kind of queries and now it makes more sense. There is something I can’t understand as you said “When I changed the first occurrence of department 1 to 432, Oracle got to the row with department 432 before it got to a row with department 1, and stored the average salary for department 432 in the hash table location that would otherwise have been used by department 1.”. Do you know about how the algorithm builds the hash table to go into this hash colission (as you called it)?
Many thanks.

By: Jonathan Lewis

Jonathan Lewis — Fri, 03 Sep 2010 11:35:44 +0000

Victor,

The transformation you’ve done to get your query is known as unnesting. In this specific case, to demonstrate a point, I blocked the automatic unnesting that the optimizer would have done; but there are some cases of filter subqueries which the optimizer won’t handle automatically that you could do this type of manual rewrite for.

By: Victor

Victor — Thu, 02 Sep 2010 14:43:03 +0000

Hi Jonathan,

Many thanks for this amazing blog.

How about using below query ? it seems then you avoid to run the subquery again and again as it does a join between emp and avg.

select
        count(*)
        from    emp,
         (  select  dept_no,
                      avg(inner.sal) sal 
               from    emp inner
              group by dept_no
            ) avg
        where   emp.sal > avg.sal
           and   emp.dept_no = avg.dept_no

Cheers,
Victor

By: No change « Oracle Scratchpad

No change « Oracle Scratchpad — Thu, 12 Nov 2009 19:52:26 +0000

[...] A small change in data can cause a huge variation in the number of times a subquery runs [...]

By: josh

josh — Mon, 19 Oct 2009 16:11:31 +0000

Hi Jonathan,

Can this type of collision happen to a character based columns not just numbers

By: Henish

Henish — Fri, 07 Aug 2009 14:14:08 +0000

Hello Sir,

It would be great if you would please flash more light on your below comment

“I defined a table with no indexes in a tablespace using freelist management, so I could make some reasonable assumptions about the way in the which the data would be inserted and queried”

Many Thanks

By: Jonathan Lewis

Jonathan Lewis — Thu, 06 Aug 2009 17:33:35 +0000

Henish,
If I’ve understood your questions, you want to know (a) why Oracle got to the row with the department set to 432 before it got to a row with department set to 1; and (b) why 432 and 1 has to the same location.

a) Although you should not rely on any specific ordering of data (or action) when using SQL, there are simple cases where the actual mechanics cannot change. I defined a table with no indexes in a tablespace using freelist management, so I could make some reasonable assumptions about the way in the which the data would be inserted and queried. In effect I was relying on my knowledge of the current internal mechanics used by Oracle – this is not something I would do for a production system.

b) The principle of hashing is that you have an infinite number of different values that you need to store as evenly as possible in a finite number of locations. Consequently you will find cases where two different input numbers hash to the same output value. I justed experimented until I found a suitable second number.

By: Henish

Henish — Tue, 04 Aug 2009 20:10:24 +0000

Respected Sir,

update emp
set dept_no = 432
where
dept_no = 1
and rownum = 1

In your above example with respect to filter you updated the first row of dept_no=1 with 432.

Also you said a statement as below

Oracle got to the row with department 432 before it got to a row with department 1, and stored the average salary for department 432 in the hash table location that would otherwise have been used by department 1

I have one confusion that who would it possible during sql execution that the row with deptno=432 appear first among other row with same department (i.e. dept_no =1)

could you please flash more light on this?

Also who could oracle hash dept_no=432 on the location where dept_no=1 would supppose to be store?

Thanks

Sir