About this tool
Enter the total row count, the page size and the page you want to inspect, and the tool works out how many rows an offset query scans for that page and how many it throws away. An offset reads the rows it skips in order to count them, so the slowdown comes from page depth rather than table size. The same page read with a cursor is counted alongside it, which turns the difference between the two styles into a number.
The second calculation covers duplicates and gaps. When rows arrive ahead of you while you are reading a list, every later page boundary shifts and rows you already saw appear again. Enter how many rows were inserted and the duplicate count is computed, together with why a cursor avoids the problem. The rows both styles scan in total while walking every page, and the ratio between them, are shown as well.
No page size is suggested because no authoritative recommendation exists. Rows scanned are counted assuming the sort column is indexed and read in that order, and a real execution plan depends on the data and statistics. This tool does not predict response times and does not declare one style correct.
Frequently asked questions
Counting the rows to skip means actually reading them. Reaching the thousandth page means reading and discarding everything before it and then returning one page. The discarded volume grows in proportion to page depth, so later pages get slower.
It asks for rows after the last value read rather than for a position in the list. Rows inserted or deleted ahead of you leave that reference value untouched, so no boundary shifts. In exchange the sort key must be unique and arbitrary page jumps are not possible.
It does not recommend a page size, predict response times or interpret execution plans. It computes rows scanned and duplicate counts and generates example queries.