Hi,
>From what you have said the cost of distinct and the function call
shouldn't be a big deal. I did wonder if you can use to_number with an
appropriate mask to avoid the function call but it's probably not even
worth bothering.
Simplifying the connect by sub-query will hopefully provide the boost you
need. The concatenated index relates to my uncertainty about how Oracle
can use them for recursive SQL. I did a simple test - creating the
following indexes:
1) Unique index on child
2) Non-unique index on parent
3) Unique index on parent, child
4) Unique index on child, parent
The table only had a handful of rows but Oracle chose to use index 1 and
index 3 for the query instead of index 2. On a table of significant volume
(I used to work on very large recursive SQL statements at one point) I
would suggest testing the indexing combinations to see what Oracle likes -
then remove the rest. Also, the requirements are different if you are
traversing the tree in both directions - you seem to only be going down the
tree.
Good luck.
Guang Mei
<[EMAIL PROTECTED]> To: Multiple recipients of list
ORACLE-L <[EMAIL PROTECTED]>
Sent by: cc:
[EMAIL PROTECTED] Subject: Re: sql query optimization
.com
11/06/2003 12:34
Please respond to
ORACLE-L
I just looked:
[EMAIL PROTECTED]> select count(*) from arc where arctype in (2999999,3000000);
COUNT(*)
----------
56932
This is about 27% of the total rows, so I will test to move them into a
new table tomorrow and this should help. I did test each part separatley
and timed them and I found that the sub-query is probably the bottle-neck
because
"start ... connect by ..." requires walk the whole index to get all
possible nodes
(expensive). I can create this new table.
> 2) Consider a concatenated index (perhaps termid, parenttermid or
> parenttermid,termid - too early for my brain to remember without trying)
>
I don't know why concatenated index would help here, for which part in
where clause it would?
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<---->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Privileged/Confidential information may be contained in this message.
If you are not the addressee indicated in this message
(or responsible for delivery of the message to such person),
you may not copy or deliver this message to anyone.
In such case, you should destroy this message and kindly notify the sender
by reply e-mail or by telephone on (61 3) 9612-6999.
Please advise immediately if you or your employer does not consent to
Internet e-mail for messages of this kind.
Opinions, conclusions and other information in this message
that do not relate to the official business of
Transurban City Link Ltd
shall be understood as neither given nor endorsed by it.
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<---->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Mark Richard
INET: [EMAIL PROTECTED]
Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
