How to find number of rows in a table

Question

i have one table ,it contains millions of record,how can i know number of rows in that table without using count(*),
i tried in user_table ,for the column NUM_ROWS,but it is not showing number of rows,pls send me a solution for this.
regards,
singh

Answer 1

Ok, that only was to show simply that max option
might not an option to reduce execution time.Yes, but I/O variances have a tendency to really skew the observed elapsed execution time - making execution time alone a poor choice to determine what SQL will perform better than another.
Both MAX(ROWNUM) and COUNT(*) results in the same amount of I/O - as both uses the exact same execution plan, I/O wise. In this example, a FTS.
SQL> create table testtab nologging as select * from all_objects where rownum < 10001;
Table created.
-- warmed up the buffer cache with a couple of SELECTs against TESTAB in order
-- to discard PIOs from the results
SQL> set autotrace on
SQL> select count(*) from testtab;
COUNT(*)
10000
Execution Plan
Plan hash value: 2656308840
| Id | Operation | Name | Rows | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 35 (9)| 00:00:01 |
| 1 | SORT AGGREGATE | | 1 | | |
| 2 | TABLE ACCESS FULL| TESTTAB | 9262 | 35 (9)| 00:00:01 |
Note
- dynamic sampling used for this statement
Statistics
0 recursive calls
0 db block gets
131 consistent gets
0 physical reads
0 redo size
223 bytes sent via SQL*Net to client
238 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
SQL> select max(rownum) from testtab;
MAX(ROWNUM)
10000
Execution Plan
Plan hash value: 2387991791
| Id | Operation | Name | Rows | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 35 (9)| 00:00:01 |
| 1 | SORT AGGREGATE | | 1 | | |
| 2 | COUNT | | | | |
| 3 | TABLE ACCESS FULL| TESTTAB | 9262 | 35 (9)| 00:00:01 |
Note
- dynamic sampling used for this statement
Statistics
0 recursive calls
0 db block gets
131 consistent gets
0 physical reads
0 redo size
225 bytes sent via SQL*Net to client
238 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
So seeing that we have the exact same baseline for both queries, and that PIO does not influence the results, we time a 1000 executions of both.
SQL> declare
2 cnt number;
3 begin
4 for i in 1..1000
5 loop
6 select count(*) into cnt from testtab;
7 end loop;
8 end;
9 /
PL/SQL procedure successfully completed.
Elapsed: 00:00:03.19
SQL>
SQL> declare
2 cnt number;
3 begin
4 for i in 1..1000
5 loop
6 select max(rownum) into cnt from testtab;
7 end loop;
8 end;
9 /
PL/SQL procedure successfully completed.
Elapsed: 00:00:15.87
SQL>
This shows that what makes the MAX() more expensive is just that - determining the MAX(). For each row, Oracle has to call its internal MAX() function with two values - the current max result and the new value. This function then returns the new max value. This overhead per row adds up to a significant overhead in execution time - making the MAX() approach 5x slower than the COUNT() approach.