One point I can help you on without the SQL and such as Jonathon has pointed out is clearing up a bit about the OPTIMIZER_INDEX_COST_ADJ parameter. The setting of 100 is the default which tells the optimizer to cost an index normally. The range of values is 1 to 1000. Setting it lower then 100 forces the optimizer to cost the use of an index cheaper and above 100 to cost if more expensively. As in, if you set this to 50, the cost of an index is cut in half and at 200 an index would be twice as expensive. Also realize that this will be applied to all indexes. Ric Van Dyke Hotsos Enterprises ----------------------- Hotsos Symposium March 4-8, 2007. Be there. -----Original Message----- From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of genegurevich@xxxxxxxxxxxxxxxxxxxxx Sent: Thursday, August 03, 2006 4:40 PM To: oracle-l Subject: Index suppression Hello everybody: I stumbled upon a SQL which executes in 20 to 30 sec the way it has been written. If I however suppress one index by replacing "table1.col1 = table2.col1" with "table1.col1+0 = table2.col1", the query executes in under 0.1sec. The explain plan shows that in the original version oracle accesses table1 via a primary key and then reads data from the table. In the modified version oracle does a full table scan. As the table1 only has 10000 rows, full table scan is probably faster than an index read followed by the table read. So I wonder why does oracle optimizer (my version is 9204) insists on using the index and how can I force it to be smarter. My optimizer_index_costr_adj is 100, which makes index as expensive as possible (I think). I can't change the multiblock_read_count. Is there anything else I am missing? thank you Gene Gurevich -- //www.freelists.org/webpage/oracle-l -- //www.freelists.org/webpage/oracle-l