The current structure for indexes was introduced in v6.

Prior to that, v5 had a compression mechanism (when machines were small and very expensive) that reduced the size of index entries using a sort of “jpeg” like algorithm that recorded changes in the leading edge and trailing edge. According to a comment that Dave Ensor once made (possibly during a SIG presentation in the UK) the mechanism was so aggressive that sometimes you got false positives – i.e. you had to visit the table to find out the actual value that had been encoded in the index, and it wasn’t always one you wanted.

The current form of index compression is nothing like th v5 form – it’s deduplication of the leading column set on a block by block basis. From memory I’d say it it appeared in v8, but I wouldn’t be surprised if someone told me it was v7.

“And talking of things I’m guilty of, another one is being too quick to bung a couple of extra columns on the end of an index because I know one or two queries will benefit. A quick win perhaps for those one or two queries, which can arbitrarily improve some performance metric when sql tuning had already achieved the benefit required, but at the expense of making the index bigger than it needs to be for everyone else.”

And, repeating Mohamed’s comment, the consequences of the change in clustering_factor can be even more of a problem. Wouldn’t is be nice if Oracle has the same “carried columns” concept that SQL Server has – i.e. the ability to add columns that don’t participate in the ordering of the index entries.

You’re quite right to emphasise how hard it can be to be change the indexes in a production system with confidence that nothing will go wrong. (Thank goodness for the advent of invisible indexes – not a 100% solution, but a most helpful option.)

Your point about the clustering_factor is paricularly significant – I may even have an article on the blog demonstrating Oracle deciding not to use an index on (cola,colb) after dropping the index on just (cola). The change in clustering_factor can have a much more profound impact on the use of the index than the change in basic size, and it’s quite hard to predict how bad things can be as a side effect.

Expensive in terms of what (latches, elapsed time, buffer gets)? And how do you calculate how expensive an index is to maintain?

What I want to emphasize is that it might exist a situation where two redundant indexes exist, t1(a,b) and t2(a) for example, and we decide to drop the t2(a) index because it is already covered by the index t1(a,b). However, we know that adding an extra column to an index might damage the clustering factor of that index. This is why t2(a) may have a better clustering factor than t1(a,b) and dropping it could make the CBO choosing another execution path that does not include an access to the remaining t1(a,b) index. This is why I always start looking at redundant index at design time.

Index compression is probably one of the the most under utilised features in the database, I know I’m guilty of just not considering it enough. I recently added it to a couple of composite indexes with 5,6 even 7 highly repetitive columns (on a wider table). Actually I’m about to do some tests on making the table concerned a partitioned IOT (back again to underutilised features) with some key compression. But just the space saving on such a repetitive key composite index is great and the performance benefit is not bad either.
But when I was looking into key compression I canvassed a couple of opinions and the general response was that they never even tend to consider it either.

And talking of things I’m guilty of, another one is being too quick to bung a couple of extra columns on the end of an index because I know one or two queries will benefit. A quick win perhaps for those one or two queries, which can arbitrarily improve some performance metric when sql tuning had already achieved the benefit required, but at the expense of making the index bigger than it needs to be for everyone else.

Sometimes it can be tricky striking the right balance.

1- Table TXN_SEARCH, 51 columns

2- Number of indexes on TXN_SEARCH: 50

They: “Nuno, can you check the database? Updating our searches is slow, must be something in your setup! Can you move to RAC?

Me: (after finding the above, slowly reaching for the BIG mattock handle…) Are you people completely insane?