I’m always allowed to say: “I don’t know, I didn’t write the spec or the code.”

I can think of a few arguments for why the row cache is a good idea, though, here’s one. Oracle developers ought to assume that people will design bad applications and find themselves constantly optimising SQL statements. To optimise a statement you have to check whether or not the objects referenced exist and aren’t being created, changed, or destroyed, so you need a mechanism to lock the object definition temporarily.

If you kept all the information in the data buffer, how would you lock the rows in the data buffer in a way that didn’t modify the data blocks (i.e. didn’t generate undo and redo) but ensured no-one could could change the row. Apart from using a whole data buffer to hold one row in memory, you’d have to write a layer of code that crossed the normal buffer handing code and introduced a level of complexity that would make it much harder to modify either set of code (i.e. the data handling code and the optimisation code).

There’s no obvious reason, although it might simply be a question of simplicity of code. At this point, of course, Oracle doesn’t know which partition it’s going to use because that information embedded in the partition definition (tabpart$) rather than the segment definition – but I think Oracle gets that various bits of object partition information before it gets the segment information anyway.

It’s interesting to note two things. First, the calls to tabpart$ and indpart$ don’t follow the same pattern – it’s one execution for the table, one for each index, with a large array fetch to get the data for all the partitions in one got. Secondly, the results above are from 11.2, and you don’t see any parse calls reported for the query against seg$, in 11.1 there is a parse call for every execution.

I suspect that there’s some history attached to this code – in the good old days partitioned objects tended to have only a few partitions, so this single-row processing didn’t seem to introduce much overhead, and the strategy probably made it easy to deal with generic code that had to handle heap table, and IOTs, and any other possible partitioned object – I suspect that what were seeing is just the effect of code that has been written with implicit cursor loops that avoids writing more complex code that deals with several variants of joins between seg$ and other data dictionary tables.