sluggish ROWNUM statement in Oracle 10g

It seems, that in some circumstances it might be faster and more efficient to use SQL queries without rownum limitation, even if you're asking for hundreds of records. We hit the exigence, where simple SELECT statement using rownum clause may paralyze whole database system by hanging up CPU ( 100% usage ).
What is database doing? Database optimizer uses another plans for both queries, unfortunately - plan for limited query causes very expensive nested loops.

Why did database spent so much time to serve few records from indexed table? I dunno.. we're working on it.. and Oracle corporation too..

Information from Oracle Corporation in reply to service request - "It is not a bug. It is an expected behavior if the nested loop order is chosen wrongly."

In my opinion it is an unexpected behavior of preparing and choosing completely wrong execution plan by database engine.

To be continued..

Finally! I'm close to the answer. Database choosen plan was inadequate, and causes not anticipate results. The only way to deal with it is to set hidden init parameter _optimizer_rownum_pred_based to false. Until used, you can't show its value using "show parameter optimizer". Parameter is hidden, not well documented and using it
is not permissive by Oracle.
With this parameter set to false, database will use first K rows plan for getting the first K rows to be returned, and plan for both queries ( with and without rownum ) looks the same. Database processes them the same way, applying stop count condition after K rows in rownum limited query.
Of course there is possibility not to change optimizer parameter. You can use hints in SQL queries, but this solution may not come true for all the situations, specially for OLTP systems and queries based on users requests.