I think that’s an important point to consider. I always prefer to make “dirty tricks” explicit if possible, and certainly document why they’re there.

That’s partly why I prefer the no_merge hint to adding a rownum – but even there I’ve been caught out by an optimisation in 10gR2 which took out an “order by” clause on an inline view with a no_merge because (as you point out) it wasn’t goint to make any difference to the final result set.

Another way to think about it is to go back to the concepts of the “left deep” and “bushy tree” optimisation plans.

The “unit of optimisation” – the thing where Oracle examines a set of possible join orders – is based on the “left deep” tree, and is the unit that Oracle calls the “query block”.

If Oracle cannot transform your query into a single query block, it has to optimise each query block separately. In effect, each query block is a non-mergeable view – and in some cases Oracle will indicate this through the use of the VIEW operator.

Unfortunately, history and development cycles being what they are (a) the appearance of the VIEW operator is not totally consistent, and (b) as time passes the optimizes is enhanced to improve it’s ability to transform more complicated queries into single query blocks.

Finally – compare a query block with a single table: there are execution plans where Oracle has to process the whole of table 1 before touching table 2; (e.g. hash join) there are execution plans where Oracle processes a bit of table 1 then a bit of table 2, and alternates between them (e.g. nested loop join) – the same type of thinking applies to query blocks, some have to be evaluated completely before they can be used, some can be evaluated piecewise.

I’ll try to remember to produce a different example some time over the next few weeks.

Addressing the rownum issue specifically – I think that Tom has pointed out in the past that if you “select rownum” it’s a very good way of forcing Oracle to materialize the result set. The example you’ve referenced is using a “rownum <= N" clause which limits the results returned from select. This has a very different effect, and can be optimised in various ways in different versions of Oracle.

Even in the case of the "select rownum" though, I've never been certain that the full result set has to be materilized before any of it can be used – it probably depends on the exact nature of the surrounding query.

Thanks for your reply. I have not managed to test the scenario but what has surprised me is that Tom has suggested that “it never had to” materialize as a result of using ROWNUM. I believe that means it was the case in versions prior to 10g, as well.

This may be related:

As of 10.2.x.x and up there is a parameter called OPTIMIZER_SECURE_VIEW_MERGING (http://download.oracle.com/docs/cd/B19306_01/server.102/b14237/initparams146.htm) that can prevent merging from happening and cause a view to materialize. Christian Antognini has an excellent explanation in his book Troubleshooting Oracle Performance.

Thanks. It is nice to read about EXPLAIN PLAN output in between.
Now, I had this doubt since I read one of Tom’s responses recently
(http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:2853107469873#1772855900346026443)
What makes CBO decide NOT to merge inline views/subqueries? I had thought use of ROWNUM (and GROUP BY, DISTINCT etc.) would FORCE the optimizer to materialize the subquery/inline view. Apparantly, Tom suggests that is not the case.
I am especially puzzled about ROWNUM not forcing the subquery to materialize.
Any chance you can throw some light?