Re: Composite indices and skip scanning

It's a statistical thing.
A skip scan would be:
    For each value of pk_table_a
        find values for pk_table_b

It's likely to be cheaper than a tablescan
only if there are relatively few distinct values 
for the column pk_table_a.

If you're looking for ideas for minimising
I/O and improving performance - you 
could investigate defining the intersection
table as an IOT, with compression on the 
pk_table_a column; and then create a
compressed secondary index on pk_table_b.
In the right circumstances it might be the 
most efficient option.

Regards

Jonathan Lewis
http://www.jlcomp.demon.co.uk

The Co-operative Oracle Users' FAQ
http://www.jlcomp.demon.co.uk/faq/ind_faq.html

April 2004 Iceland  http://www.index.is/oracleday.php 
June  2004      UK - Optimising Oracle Seminar


----- Original Message ----- 
From: "Boyle, Christopher J." <Christopher.J.Boyle@xxxxxxxx>
To: <oracle-l@xxxxxxxxxxxxx>
Sent: Thursday, April 15, 2004 2:11 PM
Subject: Composite indices and skip scanning


Oracle 9.2.0.2.0=20

I have an intersection table composed of PK_TABLE_A, PK_TABLE_B which is
being used to handle a M:M relationship between A and B.  There is a
unique constraint on the combination of the two entries and a
corresponding index with A as the leading value.  When I was trying to
access table A using the PK from table B I expected it to use that index
because of the 9i skip scan feature that allows for a non leading index
member to still utilize the index.  What I got was a FTS until I added a
separate index on PK_TABLE_B only.  Is there something with a unique
index that prevents skip scanning? Or do I have too much blood in my
caffeine and am mis-rembering how the indices should work?

Thanks,
Chris =20


----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------

Other related posts: