-
performance of Indexes in Composite key
hi
i have table having composite primary key on four fields.
According to my knowledge oracle has indexed in the sequence of fields i have given like " Primary key(f1,f2,f3,f4) "
Now
first is:
if i give my where condition like: "where f1='some value' and
f2='some value' and f3='some value' and f4='some value'"
Note : in above where condition i have taken the same sequence for fields as it is in compsite primary key.
Second is:
if i give my where condition like: "where f3='some value' and
f2='some value' and f1='some value' and f4='some value'"
Note : in above where condition it have not taken the same sequence for fields as it is in composite primary key.
Now my First question is which query will give me the better performance weather index created by composite primary key will work?
Second Question is if i take single any field in where condition like :
"where f3='some value' "
then the index created by composite primary key will work or not
thanx
Avi
-
Re: performance of Indexes in Composite key
Originally posted by avi kumar
Now my First question is which query will give me the better performance weather index created by composite primary key will work?
Both will result in the same execution plan, hence the same performance in both cases. Composit index will (or will not) be used in botrh cases if optimizer chooses so. Nothing is preventing the usage of composite index in both cases, though.
Second Question is if i take single any field in where condition like :
"where f3='some value' "
then the index created by composite primary key will work or not
Generaly, in this case the composite index can not be used unless f3 is the leading column of the index.
However in 9i cost based optimizer might choose to use your composite index even if f3 is not the leading column of the index.
Last edited by jmodic; 01-23-2003 at 09:53 AM.
Jurij Modic
ASCII a stupid question, get a stupid ANSI
24 hours in a day .... 24 beer in a case .... coincidence?
-
1. It will/will not use a composite index for two first queries though the columns mentioned in the WHERE clause aren't as specified in the index defination (sequence of column specification). BUT It will definately improve the speed of retrival of data if you specify the sequence of the columns in the WHERE condition as you specified in the index defination. As it is always recommended
Look at the follwing example.
Code:
SQL> CREATE TABLE test AS SELECT object_id, object_name, object_type FROM all_objects;
Table created.
SQL> CREATE INDEX ix_test ON test (object_id, object_type);
Index created.
SQL> SELECT object_name FROM test WHERE object_id = 1199 AND object_type = 'VIEW';
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE
1 0 TABLE ACCESS (BY INDEX ROWID) OF 'TEST'
2 1 INDEX (RANGE SCAN) OF 'IX_TEST' (NON-UNIQUE)
SQL> SELECT object_name FROM test
2 WHERE object_type = 'VIEW' AND object_id = 1199;
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE
1 0 TABLE ACCESS (BY INDEX ROWID) OF 'TEST'
2 1 INDEX (RANGE SCAN) OF 'IX_TEST' (NON-UNIQUE)
-- only second column has been specified in the WHERE clause
so it doesn't use the index.
SQL> SELECT object_name FROM test
2 WHERE object_type = 'VIEW' ;
1155 rows selected.
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE
1 0 TABLE ACCESS (FULL) OF 'TEST'
SQL> SELECT object_name FROM test WHERE object_id = 1199;
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE
1 0 TABLE ACCESS (BY INDEX ROWID) OF 'TEST'
2 1 INDEX (RANGE SCAN) OF 'IX_TEST' (NON-UNIQUE)
-- Here you force optimizer to user index by suppling hint
SQL> SELECT /*+ INDEX (test, ix_test) */ object_name FROM test WHERE object_type = 'VIEW' ;
1155 rows selected.
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=34 Card=10 Bytes=280
)
1 0 TABLE ACCESS (BY INDEX ROWID) OF 'TEST' (Cost=34 Card=10 B
ytes=280)
2 1 INDEX (FULL SCAN) OF 'IX_TEST' (NON-UNIQUE) (Cost=26 Car
d=10)
Last edited by Sameer; 01-23-2003 at 10:01 AM.
-
Originally posted by Sameer
BUT It will definately improve the speed of retrival of data if you specify the sequence of the columns in the WHERE condition as you specified in the index defination. As it is always recommended
Hmm, hmm, .... What makes you belive this? It will definately NOT HAVE ANY INFLUENCE WHATSOEVER in the speed of retrival of data if you specify the sequence of the columns in the WHERE condition as you specified in the index defination. The order of conditions in WHERE close is irrelevant.
Jurij Modic
ASCII a stupid question, get a stupid ANSI
24 hours in a day .... 24 beer in a case .... coincidence?
-
Originally posted by jmodic
It will definately NOT HAVE ANY INFLUENCE WHATSOEVER in the speed of retrival of data
Sorry.. I agree, I take the sentence back.. my mistake!!
-
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|