Remember that the index is on trunc(last_update_date) – so the virtual column value is a constant for 24 hours. Since each index entry (non-unique index, remember) is then (column_value, rowid), the order in which we update the old value could affect the rows in an order that allowed earlier rowids to be updated after later rowids, filling in gaps in the index leaf blocks for the current date.

Nice presentation

“However, rather than take the worst case scenario, let’s take the best (and least likely) scenario – assume that by the end of the
day there have been lots of 50/50 block splits, but a lot of back-fill has taken place (because of a random order of updates) and
every block just happens to get very close to 100% full.”

since the column last_update_date always reflect to the future date when the update happen,
how will it back-fill

could you please explain?

Thanks

It’s always a good idea to consider reverse key indexes when you see an odd pattern of filling and emptying on an index – but I don’t think it would really have much effect in this case.

Part of the problem with this index is that there are a lot of rows for each value – around 100 leaf blocks per value. If you reverse the key value, I think you might get some benefit at the high end block for a previously loaded date (in terms of re-filling the block “earlier”) but that wouldn’t have impact overall.

If this were a really big table, though, it would be an idea that could be modelled fairly easily – maybe 3 or 4 hours of work – if you wanted to check the idea.

thanks for the additional explanation! I am afraid, I was not as clear as I would have liked to be. First, I don’t think I got an overdose from Richard – it’s just a reinforcement of my natural scepticism. :-)

Then, about the size issue – my reasoning behind this was like this: the coalesce will reduce the wasted space of the index. During the week a certain amount of wasted space is added in the way you described. This volume of “waste” is roughly the same per week because you assumed a steady rate of inserts and updates. The _percentage_ of waste thus decreases over time because the total space increases (deletion will only start in 2012). The effect (i.e. achieving minimal wasted %) of a coalesce at the beginning will be reduced by insert / update activity much faster than after a year when the table and index have filled significantly. This could be translated to : with increasing size of the index you can increase the interval of coalesce without wasting a too high _percentage_ of the space.

Few additional thoughts: if the table is expected to grow large maybe partitioning with local indexes can help limit the effort needed for coalesce because “older” partitions do not need to be coalesced any more. Another idea I had was to use a FBI to reduce the number of indexed rows but unfortunately you can’t use SYSDATE in there which you’d have to to automatically “expire” entries. After automatic partitioning in 11g maybe a rolling window for DATE and TIMESTAMP indexes would be a nice idea for Oracle 12. :-)

Cheers

Inoculation is good – an overdose isn’t. My example suggests coalescing, but there are still cases (as Richard points out) where rebuilding can be a good idea.

Your comment about the size of the index is important. In this (very specific) case, there is a rolling wedge of the index covering four to six week period that is constantly getting deletes at one end and inserts at the other – the total size of the index is irrelevant to the process of deleting from the earlier weeks and inserting into “today” – after seven years, we will still be looking at just the wedge for the most recent six weeks. Any resource wastage in this process will be due to the emptiness of the “older” leaf blocks in that wedge.

I think the image you have in mind is the index rebuild that has a packing effect on the entire index – bringing it back to its original pctfree – followed by random inserts all over the place that end up seeing an increased rate of block splits because the blocks are (temporarily) well packed. There’s a demonstration of this in an article I wrote a few years ago: http://www.jlcomp.demon.co.uk/14_index_rebuild_i.html

In the example we don’t have to worry about that phenomenon. At the start of each new day, our inserts go past the high end of the index and (apart from the current high-value block in the index) the timing of block splits will have nothing to do with the state of the rest of the index.