Comments on: Quiz Night

By: Jonathan Lewis

Jonathan Lewis — Thu, 26 Jan 2012 23:10:22 +0000

Valentin,
I think your first couple of statements summarise the informal argument about why we generally assume a two-column index will have a lower clustering_factor than a three-column index – the inclusion of the rowid in the index entry is very important, so if we have six rows with the same (two-column) key, three rows in each of two blocks (call them B1, B2) the block component of the index entries would be for (B1, B1, B1, B2, B2, B2). Adding an extra column to the index could then very easily change the order of visiting the rows to (B1, B2, B1, B2, B1, B2).

On the other hand, as you point out, there are patterns of data where an odd synchronsiation of values and block locations could contradict the general intuition.

By: Jonathan Lewis

Jonathan Lewis — Thu, 26 Jan 2012 23:00:20 +0000

Srivenu, Your blog highlights an interesting side-effect of the flaw in the optimizer's model when it comes to using the clustering_factor. (It also fit quite nicely with a little posting I did recently about enhancing index statistics to include figures about every prefix combination.)

By: Jonathan Lewis

Jonathan Lewis — Thu, 26 Jan 2012 22:56:53 +0000

Srivenu,
The mixture of local and global indexes is certainly a case where the side effects on clustering_factor can be very counter-intuitive.

On a completely different tack, creating a hash-partitioned index on a non-partitioned table could also result in less contention for popular blocks on insertion, which can avoid a bug that causes indexes to become much bigger than they need to. There’s lots of room for discusion when looking at partitioned indexes.

By: Jonathan Lewis

Jonathan Lewis — Thu, 26 Jan 2012 22:40:05 +0000

Martin,
I wasn’t thinking about bitmap indexes when I posed the question, but my first thought is that if (‘x’,'y’) is a key value in the two-column index then it may have one index entry; if you add a third column you may have N index entries like (‘x’,'y’,'a’), (‘x’,'y’,'b’) – with a corresponding increase in the clustering_factor. This won’t change the cost of using the index, of course, since the clustering_factor of a bitmap index isn’t used in the cost.

By: Jonathan Lewis

Jonathan Lewis — Thu, 26 Jan 2012 22:34:21 +0000

Stefan, As Valentin has pointed out, compression won't affect the clustering_factor, but it will affect the size (number of leaf blocks) in the index - and that does have some impact on the cost of using the index; so if you have different compression on the indexes you can get counter-intuitive results.

By: Jonathan Lewis

Jonathan Lewis — Thu, 26 Jan 2012 22:32:03 +0000

Valentin,

Another good point – it is possible to find edge cases (particularly with a small number of index entries) where the order of data arrival can have a surprising impact. In your case the effect is also largely dependent on the great length of the table rows.

By: srivenu kadiyala

srivenu kadiyala — Wed, 25 Jan 2012 12:59:19 +0000

I could think of a test case, where a 2 column global index on a partitioned table could have a higher clustering factor than a super set 3 column local index. (I dont have access to an oracle database right now to test it out).
srivenu

By: srivenu kadiyala

srivenu kadiyala — Wed, 25 Jan 2012 11:16:21 +0000

Jonathan,
I’m working on a test case scenario (looks tricky!)
I posted something recently
http://srivenukadiyala.wordpress.com/2011/12/25/optimizer-might-ignore-a-more-suitable-superset-composite-index/
regards
srivenu

By: Alexandru Ersenie

Alexandru Ersenie — Tue, 24 Jan 2012 11:24:33 +0000

Guess it’s all a question of math. 2 columns index, combination of two values. 3 Columns index, combination of 3 values, taken by three. There goes your clustering factor…the last column increases the number of combinations possible. Of course compression will save something,but compression is used (correct me if i’m wrong) for the prefix, not the sufix, meaning:
in a two column index, you can compress the first column
in a three column index (depending on the density of the second column) you can compress the first two columns.

Still, that will not be the deciding factor.
Fact is: third column value has to be stored in the index. Clustering factor increases due to the number of combinations.
Maybe i’m wrong, but that’s how i see it.
Alex

By: Michael vR

Michael vR — Fri, 20 Jan 2012 09:11:37 +0000

For a bulk loaded table the CF for the 2-column table should be at least as good as the CF of the 3-column table.
If the data is not bulk loaded and the third column increases for each insert (for example insertion date) I would expect a better CF for the 3-column table.