Does index work below 300 row result set

Question

Hi,
Today I was in discussion with database team.
One of my dba created tables without any PK.
I asked why you have not created any PK and indexes.He replied that Index will not work if table holds less than 300 rows.
It seems strange to me as per my understanding DBMS parse and make plan on the basis on indexes rather number of rows in table.
what are your thoughts?

Answer 1

More to add see below:
17:08:33 SQL> create table raks as select * from dba_objects where rownum < 250;
Table created.
Elapsed: 00:00:00.61
17:08:44 SQL> select count(*) from raks;
COUNT(*)
249
Elapsed: 00:00:00.06
17:08:51 SQL> create index raks_indx on raks(object_id);
Index created.
Elapsed: 00:00:00.14
17:08:58 SQL>
17:08:58 SQL> exec dbms_stats.gather_table_stats('KYADAV','RAKS')
PL/SQL procedure successfully completed.
Elapsed: 00:00:01.15
17:09:28 SQL> exec dbms_stats.gather_INDEX_STATS('KYADAV','RAKS_INDX')
PL/SQL procedure successfully completed.
Elapsed: 00:00:00.00
17:09:40 SQL> explain plan for select object_id from raks where object_id =212;
Explained.
Elapsed: 00:00:00.23
17:09:54 SQL> set linesize 200
17:10:07 SQL> set pagesize 100
17:10:11 SQL> select * from table(dbms_xplan.display());
PLAN_TABLE_OUTPUT
Plan hash value: 1512471328
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 4 | 1 (0)| 00:00:01 |
|* 1 | INDEX RANGE SCAN| RAKS_INDX | 1 | 4 | 1 (0)| 00:00:01 |
Predicate Information (identified by operation id):
1 - access("OBJECT_ID"=212)
13 rows selected.
Elapsed: 00:00:02.11
17:10:26 SQL> explain plan for select * from raks where object_id =212;
Explained.
Elapsed: 00:00:00.00
17:10:51 SQL> select * from table(dbms_xplan.display());
PLAN_TABLE_OUTPUT
Plan hash value: 3252694299
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 75 | 2 (0)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| RAKS | 1 | 75 | 2 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | RAKS_INDX | 1 | | 1 (0)| 00:00:01 |
Predicate Information (identified by operation id):
2 - access("OBJECT_ID"=212)
14 rows selected.
In nutshell it will use index as long as indexed column is in where clause of query and optimizer thinks that full table scan will be slower than index scans.
Note: When you are satisfied with some answer then not only mark the thread answered but also rewards to proposed solution if works for you.
Regards,
Virendra