I’ve tested a little bit queries against v$sql_plan: pure hierarchical query vs. CSE (with + materialize) and subsequent CONNECT BY. Here are some results:
1) when materialization kicks in everything works perfect (fast, minimum CPU used)
2) CONNECT BY is slower and more CPU expensive
3) as I was afraid of, materialization (with a query selecting from v$sql_plan) is not happening in some versions. (+) – works, (-) – no:
(+) 9.2.0.8 Linux 64bit with RBO (no stats for SYS schema)
(+) 11.1.0.7 Win XP 32bit
(-) 10.2.0.3 Linux 32bit
(-) 10.2.0.4 Win 2000 32bit
(-) 11.1.0.6 Win 2000 32bit
It means that there still will be problems accessing v$sql_plan using CONNECT BY in some Oracle versions. They may be avoided using additional “self-made” materialization using additional INSERT into previously created table. This will work always as expected.

Thanks for the information about issues in 9.2.0.6, I have never seen that behavior.

>Regarding the connect by issue, yes the “bug” describes something similar
I would say this is exactly what happens with incrrectly written CONNECT BY, and v$sql_plan is not an exception – something similar is typical for hierarchical queries against complex trees. Yes, data set materialization and subsequent CONNECT BY against it is also a thing to make it work correctly. But MATERIALIZE would require additional work to be done (create in memory GTT, direct path insert plus FTS) + it may not work as expected since MATERIALIZE is undocumented and there are cases when it does not work. I think it should be measured which approach is better, but I prefer straight CONNECT BY.

Regarding feeadback. I have not used scripts yet, and my first impression is based on your example.
1) *Maybe* it’s better to have the same naming conventions for columns as DBMS_XPLAN has (E-Rows, A-Rows, etc.)
2) Your idea about additional information (cursor address, first parsed at + time ago) is quite useful and info sits in right place
3) Placing additional character(s) to identify type of a predicate (F/A) in a plan is brilliant! It is so good that I think it should be moved to DBMS_XPLAN via enhancement request.

a) we fetch data form v$sql_plan once and revisit the fetched data later. that way we don’t need so much library cache latching if we used connect by directly on the v$sql_plan

b) the connect by would have less data to walk through

It’s great to hear that!

In 9.2 you can use alter session set statistics_level=all (or alter session set “_rowsource_execution_statistics”=true) to get the stats in v$sql_plan_statistics). Note that I’ve seen a problem in 9.2.0.6 where these stats werent populated even after setting the parameters (for cursors opened from PL/SQL I think). The workaroud is to enable sql_trace as well to get v$sql_plan_statistics populated and then you can use xmsh to report it again.

Feel free to give any feedback & improvement requests!