At 05:58 PM 28/11/2003 -0800, you wrote:

>This index has many millions of duplicates, as a single stock id is found
>in many tens of thousands of rows in the stockpricetable. Data inserts
>are slowed significantly by this index: removing it almost doubled import
>speed. Without it, though, selects are incredibly slow, as one would expect:
>
>PLAN(STOCKPRICETABLE NATURAL)
>
>After reading the latest threads, and thinking I understood them, I tried
>this:
>
>CREATE ASC INDEX STOCK_PRICE_STOCK_INDEX ON
>STOCKPRICETABLE(STOCKPRICE_ID,STOCK_ID);
>
>However, the plan selected is still STOCKPRICETABLE NATURAL.
>
>So clearly, I have misunderstood the heart of the select query efficiency
>conversation that has been going on here. If some expert could please
>enlighten me as to what I am missing, I would greatly appreciate it! Or
>should I just leave the original index in place, inactivate it at the
>start of a bulk-insert, and then reactivate it at the end of the insert,
>and live with the millions of duplicates?

Dan,
I think you've kinda drawn the wrong conclusion here. Turn that index
around so that STOCK_ID comes first. As you have it, it's not going to get
used for a "WHERE STOCK_ID = " search.

heLen