Behaviour of sub query wrapped in a pagination select statement and ROWNUM

Question

I've used the following "wapper" to implement pagination on a few occassions, and often referred to it as a "standard paging select". So to paginate the results from any select statement, simply wrap the select statement in a "standard paging select".

    SELECT * FROM (SELECT a.*, ROWNUM rnum FROM ((


    ( subquery:  put your select * from .......  here ..)


)) a WHERE ROWNUM  <=  ${resultEnd} ) 
WHERE rnum  >=  ${resultStart}

My question is with respect to behaviour of the paging bit and the magic around ROWNUM. From my understanding the subquery does not select the full resultset each time, and was looking for confirmation or otherwise?

Is the following, a correct description of the paging behaviour shown above, for example if page size were 50:

to select:

• Page 1(eg 0-50)subquery selects 0-50 rows
• Page 2(eg 51-100)subquery selects 0-100 rows(outer query then limits it to 50-100)
• Page 3(eg 101-150)subquery selects 0-150 rows(outer query thenlimits it to 101-150)
• Page 4(eg 151-200)subquery selects 0-200 rows(outer query then limits it to 151-200)
• Page 5(eg 201-250)the subquery selects 0-250 rows(outer query then limits it to 201-250)

... and so on, you can see the pattern.

The further you go into the "pages" the more work the subquery has to do. Is this correct? If so how does ROWNUM do this?

Thanks in advance. And feed back appreciated

Answer 1

Your understanding is generally correct. The inner rownum <= end will "interrupt" the inner query once it has produced end rows, and the outer rownum >= start discards the first rows.

rownum is generated on the fly, and the optimizer knows about rownum < filters, so it can influence the row source and stop it short (look for COUNT STOPKEY lines in the explain plan, that's what you'll see if it works).

But there is no guarantee that the inner select will be stopped short. In particular, an order by clause in there might force the whole resultset to be generated, and then the rownum filters simply discard the generated rows outside that interval.

Answer 2

If the query is well indexed and performs well, why not try using a materialized view? You can define rownum as a column and refresh the view on demand. Also just a heads up.. Oracle 12C is coming with an excellent support for pagination type query.