John, Couldn’t really get the co-relation cum the impact of blevel over Optimizer. blevel (indicating the depth of the index) how exactly, this plays a role while execution path is selected.

Tried your test case local index-List Partition, Got similar plan with Cost 14 and never got 8 post manipulation/hack of index stats.

Appreciate your splendid services to the Oracle Community.

Thanks for your time.

Regards
V.Hari

The benefit is that it is a very clear demonstration of the principle, and the scale of change.

It shouldn’t really be necessary to follow this up with a demonstration showing that execution plans can change when the cost of using a given index changes.

That certainly makes sense – given the limited amount of information I’ve supplied about the system, and in some ways is very similar to Todor Botev’s suggestion on the previous blog entry to reduce the table to just two partitions – “old” and “new”.

In fact it might even be possible to implement your suggestions invisibly by creating a constraint-base partition view on top of the two tables and writing pre-insert/update/delete triggers on the view to make sure the data goes into the right place as a short-term strategy for mnimising the code change required. Depending on the definition of the primary key, splitting the table into two might even make it possble to define the “completed” table as a range-partitioned table so that we could make history read-only and do some compression.

Yes, slightly more complicated, but then you don’t have to deal with any of these problems.