Comments on: Predicate (again)

By: Interpreting Execution Plan | Mohamed Houri’s Oracle Notes

Interpreting Execution Plan | Mohamed Houri’s Oracle Notes — Sat, 18 May 2013 11:04:10 +0000

[…] looking carefully to that execution plan and to its predicate part (always consider the predicate part) I ended up asking myself the following […]

By: Tuning a SQL query using TKPROF «

Tuning a SQL query using TKPROF « — Thu, 07 Jun 2012 08:34:40 +0000

[...] deliberately omitted to show the predicate part of this explain plan because my first reaction to this e-mail was to ask for the real [...]

By: Explain Plan Shows a Cartesian Merge Join, How Would You Help? « Charles Hooper's Oracle Notes

Fri, 24 Dec 2010 12:28:52 +0000

[...] Cartesian joins are not automatically a sign of problems. Previous blog articles have demonstrated that a Cartesian join may be more efficient than other methods for certain situations (see Improving Performance by Using a Cartesian Join and Improving Performance by Using a Cartesian Join 2), the execution plan may simply display a Cartesian join rather than a nested loops join when one of the row sources is expected to return a single row, or the optimizer may introduce a Cartesian join as a transformation due of transitive closure (see this article). [...]

By: Jonathan Lewis

Jonathan Lewis — Sat, 17 Apr 2010 11:01:05 +0000

Randolf,

Thanks for addressing Henish’s question, and for the comment on adaptive cursor sharing.

By: Henish

Henish — Fri, 16 Apr 2010 21:16:26 +0000

timur : Thanks for the link

Randolf: Thanks for your valuble input, yes you get my point correctly

Thanks for clarification

Henish

By: Randolf Geist

Randolf Geist — Fri, 16 Apr 2010 18:22:17 +0000

> you said there is many child cursors and they have same plan_hash_value who could be this possible

Timur,

as I understand the question I think it is more about the relation between multiple child cursors and the same execution plan – which is something quite usual, since e.g. CURSOR_SHARING=SIMILAR creates a new child cursor under certain circumstances (as outlined by Jonathan) that gets then optimized again. It may very well happen that this repeated optimization leads to exactly the same execution plan / PLAN_HASH_VALUE.

I guess Henish is under the impression that different child cursors would only be created if the optimization lead to different plans, but this is not the case with CURSOR_SHARING=SIMILAR. It is the other way round – a new child cursor is created (for different input values) and gets then optimized. Whether the resulting plan will be different or not doesn’t matter.

Adaptive Cursor Sharing is different in this regard – it tries to minimize the number of different child cursors, something that didn’t work very well in the initial 11.1.0.6 release, but has been improved in 11.1.0.7. May be this is more what Henish is thinking of.

Randolf

By: Timur Akhmadeev

Timur Akhmadeev — Fri, 16 Apr 2010 08:23:25 +0000

>you said there is many child cursors and they have same plan_hash_value who could be this possible ? Randolf Geist has a post on this topic: PLAN_HASH_VALUE - How equal (and stable?) are your execution plans - part 1

By: Henish

Henish — Fri, 16 Apr 2010 02:58:22 +0000

Hello Sir,

“We start with an SQL statement that happens to have a large number of child cursors – and every child cursor has exactly the same plan_hash_value (which almost guarantees they all have the same execution plan):”

you said there is many child cursors and they have same plan_hash_value who could be this possible ?

could you please flash more light on this
Thanks