I think the bytes column is supposed to be the bytes produced in the rowsource that will be passed up to the parent, so it should include the bytes for the rowid.

I’m thinking about the sentence “…total data volume expected from line 3 is slightly larger than the total data volume from line 4 where we extract only the rowid…”

If we look at the Projection Information you are right, but I think that in this scenario Oracle is saying something like “fast full scan of the index costs me 36 bytes, then of this 36 I take only the ROWID” that is: in a fast full scan Oracle do something like a full table scan so it reads all the index’s column(s) even if they are not needed and then selects only what really need (the Projection Information).
So in this case Bytes (column from the plan) and the Projection Information can be a bit “unrelated”.

What you think of my idea?

Bye,
Antonio

This is “just” the usual arithmetic problem that the optimizer has with dependent columns. You can see that the two columns are perfectly correlated and that the query is asking for a given overlap. The optimizer sees only that we have two columns that are each asking for 1/30th of the data so, ignoring some of the fiddly bits it’s arithmetic is “total_rows * 1/30 * 1/30″ (which isn’t 3, but it’s a lot closer than the 50 you’re expecting.

Nice article just a quick question why the rows column of the execution plan show 3 row in the final step (i.e. id=0)
it should be 50 right (or at least close to 50 if there is some arithmetics error)?

OR am i missing something?

Many Thanks

It might appear this evening while I’m waiting in Heathrow airport for a flight to Geneva, or it might appear on Friday evening while I’m waiting in Geneva airport for a flight home – but it will be here soon. (And then there are two more articles I could write on the topic.)

As I said at the time – it was a good question.

There are no histograms on the columns. It’s a question worth asking because it might (in theory) make some sort of difference. In fact all three columns are uniformly distributed (rownum) with no gaps in the range, so Oracle’s analysis of the data in its default “gather stats” calls shouldn’t produce histograms.

Another point about stats, though, is that I’ve disabled CPU costing (system statistics) to make the results as consistent as possible across different versions of Oracle – and you might wonder whether CPU costing would be enough to switch the order of the join.

Do we have histograms on these columns, Also i would like to see the result with oracle 11g column statistics.

Regards
Amir Riaz