Connect by prior performance

Question

In our application, we have a lot of 'trees' in our data (parent/child relationships within a table). We rely heavily on 'connect by prior' to search through the trees, to find for example values that are defined in one of the parents ('inheritance').
Lately however, we've been eliminating connect by priors wherever we can lately, because performance is dramatic. No matter what indexes we use, we keep getting full tablescans on large tables because of the connect by priors. Views with 2 connect by priors are deadly for performance.
What is a good way to optimize connect by priors?
As an example of why we use connect by prior, consider this:
table A
ID   PARENT_ID   NAME    LENGTH
1    NULL        root    10
2    1           child   NULLWe consider record 2 'derived' from record 1, inheriting its length. The alternative for connect by prior is to populate the child length whenever the master length changes, and this is what we do in most situations now, but it's hell to keep track of this. If a record changes, you would still have to go down the tree to change all child lengths etc, so we rather use connect by prior.
Any ideas?

Answer 1

Ivo, would you please post the table definition (if different than your example), the actual list of indexes, a sample query, and the explain plan for that query?
I use hierarchical queries extensively on tables with millions of rows. They work very well if all the pieces are in place. Let's see if we can get your queries humming...