Slow connect by ... start with subquery in 9i

Question

Has anyone come across a performance problem (compared to 8i) when using hierarchical queries where the START WITH list is generated by a subquery? The culprit seems to be an extra visit to the subquery block as part of the CONNECT BY WITH FILTERING operation.
For example, take a simple tree structure:
CREATE TABLE tree
id NUMBER,
parentid NUMBER
CONSTRAINT tree_pk PRIMARY KEY (id)
...and a subquery - here just a table called sample with a subset of the ids from the tree table:
CREATE TABLE sample
id NUMBER,
CONSTRAINT sample_pk PRIMARY KEY (id)
...with which to drive the start points of the treewalk:
SELECT parentid, id, label
FROM tree
CONNECT BY PRIOR parentid = id
START WITH id IN
SELECT id FROM SAMPLE
With the tables populated and analyzed, I get this from 8i:
Execution Plan
.0......SELECT STATEMENT Optimizer=CHOOSE (Cost=2 Card=1 Bytes=19)
.1....0...CONNECT BY
.2....1.....NESTED LOOPS (Cost=1 Card=1280 Bytes=10240)
.3....2.......INDEX (FAST FULL SCAN) OF 'ID_PK' (UNIQUE) (Cost=1 Card=1280 Bytes=5120)
.4....2.......INDEX (UNIQUE SCAN) OF 'TREE_PK' (UNIQUE)
.5....1.....TABLE ACCESS (BY USER ROWID) OF 'TREE'
.6....1.....TABLE ACCESS (BY INDEX ROWID) OF 'TREE' (Cost=2 Card=1 Bytes=19)
.7....6.......INDEX (UNIQUE SCAN) OF 'TREE_PK' (UNIQUE) (Cost=1 Card=1)
Statistics
.....0..recursive calls
.....4..db block gets
.15687..consistent gets
....59..physical reads
.....0..redo size
223313..bytes sent via SQL*Net to client
.38276..bytes received via SQL*Net from client
...343..SQL*Net roundtrips to/from client
.....3..sorts (memory)
.....0..sorts (disk)
..5120..rows processed
and this is 9i:
Execution Plan
.0......SELECT STATEMENT Optimizer=CHOOSE (Cost=2 Card=1 Bytes=19)
.1....0...CONNECT BY (WITH FILTERING)
.2....1.....NESTED LOOPS
.3....2.......NESTED LOOPS (Cost=2 Card=1280 Bytes=10240)
.4....3.........INDEX (FAST FULL SCAN) OF 'ID_PK' (UNIQUE) (Cost=2 Card=1280 Bytes=5120)
.5....3.........INDEX (UNIQUE SCAN) OF 'TREE_PK' (UNIQUE)
.6....2.......TABLE ACCESS (BY USER ROWID) OF 'TREE'
.7....1.....NESTED LOOPS
.8....7.......BUFFER (SORT)
.9....8.........CONNECT BY PUMP
10....7.......TABLE ACCESS (BY INDEX ROWID) OF 'TREE' (Cost=2 Card=1 Bytes=19)
11...10.........INDEX (UNIQUE SCAN) OF 'TREE_PK' (UNIQUE) (Cost=1 Card=20480)
12....1.....INDEX (UNIQUE SCAN) OF 'SAMPLE_PK' (UNIQUE) (Cost=1 Card=1 Bytes=4)
Statistics
.....1..recursive calls
.....1..db block gets
.20525..consistent gets
....72..physical reads
...120..redo size
224681..bytes sent via SQL*Net to client
.38281..bytes received via SQL*Net from client
...343..SQL*Net roundtrips to/from client
.....9..sorts (memory)
.....0..sorts (disk)
..5120..rows processed
..so, about another 5000 logical reads, corresponding to the extra access of the sample table at the bottom of the query plan. So instead of just visiting the START WITH subquery once, to kick off the treewalk, I seem to be revisiting it for every row returned. Not too bad if that happens to be a unique index scan as here but that's not always the case.
I know I've got new options for re-writing this as a join under 9i, I'm just curious about those extra lookups and why they're necessary.
Cheers - Andrew

Answer 1

Hi Andrew,
Just noticed you message. I have exact same performance problem. It's just killing ant other processes and runs forever.
Could you please share you experience how to deal with "CONNECT BY" in 9i and also could you please tell about this option to re-write CONNECT BY as a join?
Thank you very much,
Victor