Tuesday, March 16, 2010

Query paging row count

Do we need to return the accurate query row count?

We will always evaluate the query performance and cost to get the row count, and based on function/features priority and data accuracy requirements, then decide which option to go.

Also assess which option list below that the end users value more?
    • The quick response time to return the first page
    • to get the exact row count.

Here are some options I know so far:

  • Materialize the row count in MV(Summary table), schedule a regular job to refresh the summary data.
  • Estimate the row count, by CBO parse
Here is the idea, check the plan output Rows column.

The CBO (Cost Base Optimizer) estimate it when generate the SQL execution plan.
CBO get it from object(table/index) stats, e.g. dba_tables.num_rows .
But not touching the table.

scott@txdev_FLURRY> set autot trace exp
scott@txdev_FLURRY> select * from emp;
Elapsed: 00:00:00.01

Execution Plan
Plan hash value: 3956160932

| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT  |      |    14 |   518 |     3   (0)| 00:00:01 |
|   1 |  TABLE ACCESS FULL| EMP  |    14 |   518 |     3   (0)| 00:00:01 |

  • Estimate the row count, with oracles SAMPLE clause
  • Hard limit in Transactional database API,
Show user that there could be more rows than hard code limit, and always enable [Next Page] button, and dynamic change or increase the count number as paging forward.

SELECT count(*) from scott.emp where rownum <= 100;

No comments: