Optimizer choosing full partition scan over partition index scan - oracle

Question

I have a table(table1) monthly partitions on dt column. I have create a local index on dt column. When I run the below query I see optimizer going for full partition scan instead of using the index on dt column.
WITH
A AS
(
Select * from table1
WHERE
EXISTS (SELECT u_id FROM table2
WHERE u_id=UPPER('ABC'))
)
SELECT DISTINCT
A.id,
A.dt
FROM
A
WHERE
A.dt BETWEEN timestamp '2022-04-01 00:00:00' AND timestamp '2022-04-01 23:59:59.999000000'
Explain plan
----------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | Pstart| Pstop |
----------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 755K| 67M| | 34447 (1)| 00:00:02 | | |
| 1 | HASH UNIQUE | | 755K| 67M| 75M| 34447 (1)| 00:00:02 | | |
|* 2 | FILTER | | | | | | | | |
| 3 | PARTITION RANGE SINGLE| | 755K| 67M| | 18298 (1)| 00:00:01 | 5 | 5 |
|* 4 | TABLE ACCESS FULL | TABLE1 | 755K| 67M| | 18298 (1)| 00:00:01 | 5 | 5 |
|* 5 | INDEX UNIQUE SCAN | SYS_C0099684 | 1 | 15 | | 0 (0)| 00:00:01 | | |
----------------------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - filter( EXISTS (SELECT 0 FROM "TEST"."TABLE2"
"TABLE2" WHERE "U_ID"=U'ABC'))
4 - filter("TABLE1"."DT"<=TIMESTAMP' 2022-04-02 23:59:59.999000000' AND
"TABLE1"."DT">=TIMESTAMP' 2022-04-02 00:00:00.000000000')
5 - access("U_ID"=U'ABC')

Answer 1

First of all, I'm not sure that INDEX RANGE SCAN would be better here:
We don't know your average row length, so maybe full partition scan using multiblock reads would be faster than sequential single block reads of the index and partition (table access by rowid), especially considering that you need 1/30 part of the partition.
Just consider the following example:
partition size = 100 GB
rows in partition = 400 million
avg row length = 100GB/400M =~ 250 byte
Since we need 1 day, we should get ~400M/30 = 13.3M rows. That means that in case of index range scan we need 13.3 M single block reads only to get column "id" from the table by rowid from the index (table access by rowid), and that's even without counting single block reads required from the index scan. Assume, that your average single block read time is 3ms in that system, so you will need more than 13.3M * 3ms = 40000 seconds only to read table rows in case of index access.
Now consider full partition scan. If your multiblock_read_count = 64 (if I remember correctly by default it's 128) and block size is default 8kB, you will need to perform 100GB/(64*8kB) = 195k multiblock reads. Assuming that your multiblock read time is 8ms, your full partition scan would take just ~1500 sec