Comments on: first_rows_N again

By: Rownum effects « Oracle Scratchpad

Rownum effects « Oracle Scratchpad — Thu, 30 Sep 2010 18:43:31 +0000

[...] pointed out that a predicate like “rownum <= N" generally makes the optimizer use “first_rows(N)” optimisation methods – known in the code as first_k_rows [...]

By: Blogroll Report 08/01/2009 – 15/01/2010 « Coskan’s Approach to Oracle

Blogroll Report 08/01/2009 – 15/01/2010 « Coskan’s Approach to Oracle — Tue, 02 Feb 2010 18:58:36 +0000

[...] 23-Possible reason begin poor performing first_rows_n ? Jonathan Lewis- first_rows_N again [...]

By: Jan-Marten Spit

Jan-Marten Spit — Wed, 27 Jan 2010 23:36:08 +0000

another problem with first rows i frequently see (at least on 10.2.0.3 and 10.0.2.4)

select
from
where
very_selective=bind
order by field1, field2

where there is an index on (field1,field2), but the query does not filter on these in any way. there is also an index on very_selective.

now to honour the first rows, oracle seems to like the index (field1,field2) to get the data ‘already sorted’, and then filters out the very_selective field, ignoring the index on it. it takes ages. we have to force the plan; accurate statistics do not help here. the first rows is a mandatory setting enforced by the application… any ideas on the mechanics here?

By: Henish

Henish — Tue, 19 Jan 2010 21:00:55 +0000

Hello Sir,

who about dynamic sampling will it help in this scenario?

Thanks

By: Jeffrey Kemp

Jeffrey Kemp — Mon, 11 Jan 2010 02:25:06 +0000

I come across this every now and then, usually when running adhoc queries. A variation is with a ROWNUM predicate, e.g. WHERE ROWNUM<=5; if there are only 4 matching rows in the table, the query will not return until it's finished the full scan.