Thanks for the bug number.

I think I heard the word “operation” and assumed that an operation would automatically correspond to a line in an execution plan.

It’s an important difference, and I’d hope that it would be visible and controllable by a hint because there are other ways that the side effects of a sort could make a big difference to performance.

I was trying to pack too much into too few words.
I just hinted a tablescan, which managed to operate as serial direct and therefore used a smart scan.

It was a pleasure meeting so many of the faces that I’ve only exchanged email with.
Thanks for the patch number.

So, you might ask, how will the patch optimise for indexed access in Exadata ? The optimizer will be allowed to introduce a new operation between an “index range scan” and a “table access by rowid” – and the operation will be called (something like) “sort by datablock address”

I had impression it will be done by run-time with no plan change. But I might be wrong, I listened and wrote concurrently.

thanks

Nice to meet you at E4 last week. It looks like the first patch (optimizer stats) is fixed in the August quarterly database patch for 11.2.0.3. The bug number is 10248538. It looks like it’s planned on being included in 11.2.0.2 BP18 (scheduled for release October 2012).

Andy