Андрей Васильевич,

Пока не материализована выборка, сказать, что там будет на N-й cтранице невозможно, если не хранить это прекалькулированным. Т.е. надо выбрать весь set, который мы собираемся представлять пользователю.

Но если это много, то:
- Страница 3487 результата - это не то, что вообще обрабатываемо человеком через GUI, т.е. можно ограничиться где-нибудь 50-ю страницами при сотне результатов на странице, т.е. 5 000 записей (а может и меньше). Это скорее всего в пределах одного extent'а, т.е. с диска читается за раз.
- С сортировкой внимательно смотреть, чтобы реальной сортировки не происходило а был только index scan.

Эти 5 000 ID'шников (или пограничные значения для страниц) хранить в кэше, а для следующих (если всё-таки есть желание сохранить возможность добраться до них через UI) уже повторять запрос, по мере необходимости включая дополнительные результаты.

Ну, можно ещё MQT cоорудить:



PS Ещё момент, FETCH FIRST N ROWS ONLY игнорируется оптимизатором, а только подсказывает оптимальные размеры буферов для клиента (ну и физически ограничивает выборку), добавляйте ещё OPIMIZE FOR N ROWS, хотя в данном случае может не иметь значения.
И обратите внимание на получаемые планы, для "where ID_T>=x ...", если x параметризован, то оно может превратиться в FULLSCAN по таблице.

Андрей ВасильевичНу вот почему нельзя так сделать?



BTW Почти можно (с поправкой на то, что "rows" в "n rows only" пропущено), но
- fetch first ... применяется к финальному result set'у (т.е. честно отдаст одну единственную строчку);
- order by и список колонок в result-set'е не согласуется.

Можно вот так cформулировать:


Но да, чтобы добраться до N-й страницы, нужно N запросов сделать.