Oracle hierarchical SQL - cycle clause or collection of seen elements? - oracle

Question

I have undirected and potentially disconnected graph represented as table of edges.
I need to return list of all edges reachable from given initial set of edges.
This is common task which can be found at many web sites, the recursive query with cycle clause is in many tutorials.
What particularly occupies my mind is:
In what aspect is the cycle clause better, in comparison with detecting cycles "manually"?
Example:
1
1-----2
| /|
| / |
3| /5 |2
| / |
|/ |
3-----4
4
with graph (a, id, b) as (
select 1, 1, 2 from dual union all
select 2, 2, 4 from dual union all
select 1, 3, 3 from dual union all
select 3, 4, 4 from dual union all
select 2, 5, 3 from dual union all
select null, null, null from dual where 0=1
) --select * from graph;
, input (id) as (
select column_value from table(sys.ku$_objnumset(2,4))
) --select * from input;
, s (l, path, dup, seen, a, id, b) as ( -- solution using set of seen edges
select 0, '/' || g.id, 1
, cast(collect(to_number(g.id)) over () as sys.ku$_objnumset)
, g.a, g.id, g.b
from graph g
where g.id in (select i.id from input i)
union all
select s.l + 1, s.path || '/' || g.id, row_number() over (partition by g.id order by null)
, s.seen multiset union distinct cast(collect(to_number(g.id)) over () as sys.ku$_objnumset)
, g.a, g.id, g.b
from s
join graph g on s.id != g.id
and g.id not member of (select s.seen from dual)
and (s.a in (g.a, g.b) or s.b in (g.a, g.b))
where s.dup = 1
)
, c (l, path, a, id, b) as ( -- solution using cycle clause
select 0, '/' || g.id
, g.a, g.id, g.b
from graph g
where g.id in (select i.id from input i)
union all
select c.l + 1, c.path || '/' || g.id
, g.a, g.id, g.b
from c
join graph g on c.id != g.id
and (c.a in (g.a, g.b) or c.b in (g.a, g.b))
)
cycle id set is_cycle to 1 default 0
--select * from s; --6 rows
--select distinct id from s order by id; --5 rows
select * from c order by l; --214 rows (!)
--select distinct id from c where is_cycle = 0 order by id; --5 rows
There are 2 different solutions represented by CTEs s and c.
In both solutions an edge is expanded from another edge if they have common vertex.
Solution s (seen set-based) works like flood.
It is based on mass collection of all edges on particular recursion level thanks to collect() over () clause.
Input edges are on 0th level, their neigbors on 1st level etc.
Each edge belongs to just one level.
Some edge can occur multiple times on given level thanks to expansion from many edges on parent level (for instance the edge 5 in sample graph) but these duplicities are eliminated on next level using dup column.
Solution c (cycle clause-based) is based on built-in cycle detection.
The substantial difference from solution s is in the way how rows on next recursion level are expanded.
Every row in recursive part is aware only of the information of single ancestor row from previous recursion level.
Hence there are many repetitions since the graph traversal practically generates all distinct walks.
For instance, if initial edges are {2,4}, each of them is not aware of the other one so edge 2 expands to edge 4 and edge 4 expands to edge 2. Similarly on further levels where this effect is multiplied.
The cycle clause eliminates only duplicates within ancestor chain of given row, without respect to siblings.
Various sources on the web recommend to postprocess such huge resultset using distinct or analytical function (see here).
In my experience this does not eliminate the explosion of many possibilities. For real graph with 65 edges, which is still small, the query c didn't finished but query s finished in hundreds of milliseconds.
I am interested in knowing why cycle-based solution is so much favoured in tutorials and literature.
I prefer using standard ways and don't strive to built own cycle detecting solution as I've been taught here, however the s solution works much better for me, which makes me little bit confused. (Note explain plan looks less expensive for s solution. Also I tried Oracle proprietary connect by-based solution which was slow too - I omit it here for brevity.)
My question is:
Do you see any substantial drawbacks of s solution or have any idea how to improve the c solution to avoid traversal of unnecessary combinations?

Answer 1

My experience working with SET functions such as COLLECT, DISTINCT, UNION, MEMBER OF and etc shows that they are quite slow with growing number of elements. You won't notice that until start testing with really big collections. So without going in details I would say that straight away just based on previous experience.
But it does not mean it will not work. They functions are really easy to use and code looks more readable. But they just slow comparing with alternative methods.