Count Query Performance

Question

How can we improve the perfromace of a count query?
Suppose I have a table A that holds more than 50 million rows.
Now if i want to count the no of rows which is the best one
1) Select count(*) from A.
Definitely not as it is doing a full table scan
2) Select count(primary_key) from A.
3) Select count(row_id) from A.
One more question whats the difference between select count(*) from table_name and select count(1) from table_a. Many people suggest count(1) and i dont see any reason though.
Kindly guide me.

Answer 1

> Please see my points 1,2 and 3.
Can this change the execution plan (path) of the CBO in anyway?
1. count rows
2. count rows using primary key
3. counting rows using physical row addresses
The fact is that the rows, and all the rows, need to be counted. The CBO will choose the most "attractive" I/O path - i.e. the smallest one, the one with the least amount of I/O. It does not need tricks like COUNT(1) or COUNT(PK) or COUNT(ROWID) in order to make an appropriate decision.
Example:
SQL> create table tab1 nologging as select level as ID, LPAD('*',4000,'*') as STUFF from dual connect by level <= 10000;
Table created.
SQL> set autotrace on
Running a SELECT COUNT(*) without any alternate I/O paths (no indexes exist)
SQL> select count(*) from tab1;
COUNT(*)
10000
Execution Plan
Plan hash value: 899213575
| Id | Operation | Name | Rows | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 2306 (4)| 00:00:28 |
| 1 | SORT AGGREGATE | | 1 | | |
| 2 | TABLE ACCESS FULL| TAB1 | 9982 | 2306 (4)| 00:00:28 |
Note
- dynamic sampling used for this statement
Statistics
28 recursive calls
0 db block gets
10087 consistent gets
10000 physical reads
0 redo size
208 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
Creating an PK index
SQL> alter table tab1 add constraint pk_tab1 primary key(id) using index;
Table altered.
Running the same SELECT COUNT(*) - but the CBO now sees that the PK index
is smaller and cheaper to scan than scanning the table
SQL> select count(*) from tab1;
COUNT(*)
10000
Execution Plan
Plan hash value: 1796789124
| Id | Operation | Name | Rows | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 9 (23)| 00:00:01 |
| 1 | SORT AGGREGATE | | 1 | | |
| 2 | INDEX FAST FULL SCAN| PK_TAB1 | 9982 | 9 (23)| 00:00:01 |
Note
- dynamic sampling used for this statement
Statistics
194 recursive calls
0 db block gets
131 consistent gets
20 physical reads
0 redo size
222 bytes sent via SQL*Net to client
238 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
5 sorts (memory)
0 sorts (disk)
1 rows processed
SQL>