Here is the second complete solution to the problem of dividing a table into chunks of equal size. This is the solution whose first version was marked "correct" on OTN. It is the basis for what Bryn Llewellyn calls "Approx_Method_Sql_Ashton_2" in

his white paper.

The second solution for dividing a table into equal chunks does not do a JOIN. Instead it expands extent rows that contain several chunk boundaries, using an obscure method that I need to explain.

At last, here is the first complete solution to the problem of dividing a table into 12 chunks with equal numbers of blocks. James Su and I proposed this solution on OTN, but without the "filtered_extents" optimisation.

We still want to split a table into 12 chunks with equal numbers of blocks, so we can access each chunk using a rowid range. We have the extents we need and now we need to calculate the exact chunk boundaries.

After "only" 3 posts on chunking tables, we now have the raw materials for breaking up a table into 12 chunks with equal numbers of blocks, and for getting ROWID ranges that let us access the data. Now let's chunk!

So far we've decided to access a table chunk by chunk, each chunk containing one twelfth of the tables's blocks. But first, how do we access data in a chunk of blocks? How do we even know what blocks a table has?

As I mentioned in

my previous post, the basic idea is to divide a table into 12 "equal chunks", each "chunk" being a rowid range that covers the same number of blocks (give or take 1). What does this mean? Why do this? Why divide by blocks and not rows? Here are my thoughts.

When I helped answer a

question from Jonathan Lewis on OTN, little did I know that I would become a participant in a presentation and white paper by Bryn Llewellyn on "

Transforming one table to another: SQL or PL/SQL?"
Jonathan wanted help in finishing up an efficient SQL solution for dividing a table into 12 "equal chunks", each "chunk" being a rowid range that covers the same number of blocks (give or take 1). It turned

(more...)
If you have temporal tables with date ranges, and you are sure those date ranges cannot overlap, then you can join them using

the technique in my previous post - with a few important changes!