RE: need enhance feature for CBO :)
Date: Wed, 12 Nov 2008 11:49:39 -0500
Jared asks an interesting question, but I'm even more interested in why you think
"I think scanning Primary key
more efficient rather than roundtrip read PVC_U1 index and then again read PVC_PK index, due to IOT mapping..." ?
Your query only needs the seq column. All the column seq values are in pvc_u1, which is smaller than the PK.
So of course the CBO uses the smaller index. Since both SEQ and ES are in the PK, I can absolutely guarantee that pvc_u1 is smaller than the PK, which contains them and additional columns.
Now if you needed to look up values not contained in pvc_u1 (that is other columns than SEQ and ES) that are contained in the PK, or for that matter any non-overflow column in the case of an IOT, then your concern about going back to the IOT would be valid. But the value you want IS in the index and that index is guaranteed to be the smaller object.
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org]
On Behalf Of Jared Still
Sent: Tuesday, November 11, 2008 7:44 PM To: ujang.jaenudin_at_gmail.com
Cc: Oracle Discussion List
Subject: Re: need enhance feature for CBO :)
I'm curious as to why the primary key is 5 columns, and yet you can create a unique index based on 2 columns from that same set.
Kind of an unusual design.
Certifiable Oracle DBA and Part Time Perl Evangelist
On Tue, Nov 11, 2008 at 2:49 AM, Ujang Jaenudin <ujang.jaenudin_at_gmail.com> wrote:
dear all, (sorry cross posting)
huge machine :)
CREATE TABLE PVC
(AN, SEQ, ES, ETI, ER)
ORGANIZATION INDEX <=== IOT :(
PARTITION BY RANGE (SEQ)
........... (500 partitions even more)
NOPARALLEL; CREATE UNIQUE INDEX PVC_U1 ON PVC
............ (500 partitions even more)
NOPARALLEL; there are more than billion of rows
select /*+ use_index(pvc pvc_pk) */ distinct seq from pvc;
SELECT STATEMENT ALL_ROWS
PARTITION RANGE ALL
SORT UNIQUE NOSORT INDEX FULL SCAN INDEX(UNIQUE) PVC_U1
so, my question:
- why don't oracle utilize "partition key" for this case.... (by not scanning full index will be better, because partition key based on SEQ column).
getting list of partition key is the fastest way :) - even when force using PVC_PK, CBO won't do it, I think scanning Primary key
more efficient rather than roundtrip read PVC_U1 index and then again read PVC_PK index, due to IOT mapping...
-- thanks and regards ujang | oracle dba jakarta | http://ora62.wordpress.com -- http://www.freelists.org/webpage/oracle-l -- http://www.freelists.org/webpage/oracle-lReceived on Wed Nov 12 2008 - 10:49:39 CST