index strategy on SQL tuning

[dba_admin]

Hi,

For the following query, the cost of table join between t0, t1 and t3 is very expensive. For all t1's columns used in the where clauses, I created one composite index on t1 to improve the table join. The execution plan shows the index is being used. However, the cost only reduces 10%. The actual execution time does not change too much, either. Any suggestion? Thank you.

What's your general indexing strategy? Assuming I am not concerned about the cost of maintaining the index, is it the best strategy to create indexes on ALL the columns used in the where clauses?


SELECT t1.proj_id
FROM client t0, proj t1, ref t2, proj_case t3, background_report t4
WHERE t0.comp_id IN (:sys_b_00)
AND t0.case_id = t1.assigned_to_case_id
AND t1."STATUS" = :sys_b_01
AND t1.ref_id = t2.ref_id
AND t2.ref_status IN (:sys_b_02, :sys_b_03, :sys_b_04)
AND t1.primary_case_id = t3.proj_case_id
AND t3.background_report_id = t4.background_report_id(+)

[tamilselvan]

If your SQL outputs more than 15 % of rows from a table, then you don't need to create an index.

How ever, for efficient joining between 2 tables, you need to have indexes on both tables.

Tamil

[slimdave]

Originally posted by tamilselvan
If your SQL outputs more than 15 % of rows from a table, then you don't need to create an index.

* sharp-intake-of-breath *

Do we need to have a talk about clustering factor again?

[slimdave]

Originally posted by tamilselvan
How ever, for efficient joining between 2 tables, you need to have indexes on both tables.

* another-sharp-intake-of-breath *

I would say that it sometimes helps to have an index on one table -- depends on the type of join and the data volumes involved.

[abhaysk]

Originally posted by slimdave
* sharp-intake-of-breath *

Do we need to have a talk about clustering factor again?

Tamil :

I would be sure that Dave is pointing to % of Blocks than Rows..

Aint it Dave.. to my mem we (myself & u) have had enough on this topic in some post..

[slimdave]

Indeed.

http://www.dbasupport.com/forums/sho...threadid=38893

[fossil]

Hi,

1. Query execution timing difference with or without indexes may
not be much if the tables you are joining are small (few
hundred thousand rows).

2. For joining large tables (million's of rows) you don't
need an index on any column in the where clause.

3. Multi table query will join the tables first and then
filter the rows according to the where clause. You should
not be having an index lookup for the filter.

4. Comparing the trace is the way to go.
Check the trace for query with and without indexes.

[slimdave]

Originally posted by fossil
2. For joining large tables (million's of rows) you don't
need an index on any column in the where clause.

3. Multi table query will join the tables first and then
filter the rows according to the where clause. You should
not be having an index lookup for the filter.

These statements are obviously wrong.

[fossil]

SlimmDave, Try them with/without indexes and check it out yourself.

[jmodic]

Originally posted by fossil
SlimmDave, Try them with/without indexes and check it out yourself.

Why wasting time in trying your suggestions? Anyone that has ever seriously worked with Oracle database knows that each of your four suggestions are total nonsence.
(Well, the last one can not be disputed, however in most cases you don't realy need to trace the session to come to conclusions - there are other much more lightweight methods to get the same information).