The bigger block-size without changing the pctfree is a good answer and easy to demonstrate.

The “automatic compute” for 10g is, of course, the correct answer for the redudant line.

As a side-note, it’s also possible to get significant changes in the clustering_factor of bitmap indexes by rebuilding it without changing the pctfree or block size. In 10g, the best I’ve managed so far is a drop of 33% rather then 50%. It’s a side effect of marking index entries for deletion, combined with delayed cleanout after commit.

Correct.
I was carefuly to include the stats gathering so that the statistics were current before doing the rest of the demonstration.

Taken to an extreme, of course, I could “demonstrate” any change in statistics that I wanted to by creating some data, collecting stats on that data, then changing the data again. If I published just the code from that point onwards eveyone ought to point out the error in my methodology.

Creating the correct model of the thing you’re trying to emulate can be very difficult – and it’s very easy to miss critical steps.

From memory, you are really building a bitmap index on a heap table, so (with a change in the data, possibly) you should be able to see the same effect.

I was taught that a high clustering factor is a measure of how much rows are addressed by a single entry in the index: so the lower the “closer” is the index to the table (i.e. a primary key is “1-to-1″ to the table).

In this example the change in the clustering factor from 396 to 198 would suggest that the rows in the table are “not so packed”. Probably idea this is wrong.

Keeping in mind the previous post, where Jonathan suggest that we “must” use bigger bitmap index to solve concurrency problem, the change in the clustering factor can be seen as a grow of the bitmap index.
Probably right as the change of the pctfree suggest.

Now, how all this impact performance? And how the optimizer reacts to this change?

I think that performance can be worst as the index is bigger. On the other hand the optimizer can ignore this index because of is “low” clustering factor (for example if we need to do a range scan).

How many errors I made? ^_^

Bye,
Antonio

Since its a bitmap index

“The clustering_factor has no direct connection with the scattering of data in the table”
“clustering_factor in bitmap indexes does not describe the table”

– Cost based oracle fundamentals,Jonathan lewis

And also PCTFREE of 10 is going to give more trouble for the DML.

What’s the flaw in the suggestions put forward by Chen and Wolfgang ?

The possible flaw in Wolfgang and chang is they show wrong statistics in the first place, they should have recollected the statistics after the delete statement or the shrink commands before selecting the clustering factor for thhe first time.

Which line of code in my example is redundant ?

The redundant line is the statisticss collection as the rebuild would have automatically collected the statistics.

Could I have produced the same effect without changing the pctfree

One possible option would be to rebuild the index on a bigger block sized tablespace without change in the pctfree.