My findings:<br> <b>Slow running query:</b> <pre> --------------------------------------------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop | --------------------------------------------------------------------------------------------------------------------------------------------------- | 48 | PARTITION RANGE ALL | | 1 | 82 | 34 (0)| 00:00:01 | 1 | 17 | |* 49 | TABLE ACCESS BY LOCAL INDEX ROWID| ADIO_UNIVERSOS | 1 | 82 | 34 (0)| 00:00:01 | 1 | 17 | |* 50 | INDEX RANGE SCAN | IXN_ADIOUNIVERSOS_ARINOPERLOC | 2039K| | 34 (0)| 00:00:01 | 1 | 17 | 49 - filter(("AU"."PROGRAMA_ID"=1 OR "AU"."PROGRAMA_ID"=2) AND "AU"."CARGA_VALIDA"=1) 50 - access("AAI"."ID_ARCHIVO_INSUMO"="AU"."ID_ARCHIVO_INSUMO" </pre> <b>Fast running query:</b> <pre> --------------------------------------------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop | --------------------------------------------------------------------------------------------------------------------------------------------------- |* 29 | TABLE ACCESS BY GLOBAL INDEX ROWID | ADIO_UNIVERSOS | 1 | 71 | 2 (0)| 00:00:01 | ROWID | ROWID | |* 30 | INDEX UNIQUE SCAN | PK_ADIOUNIV_IDUNIV | 1 | | 1 (0)| 00:00:01 | | | 29 - filter("AU"."CARGA_VALIDA"=1) 30 - access("AU"."ID_UNIVERSO"="PPU"."ID_UNIVERSO") </pre> I found that the table 'ADIO_UNIVERSOS' is accessed by local index 'IXN_ADIOUNIVERSOS_ARINOPERLOC'(INDEX RANGE SCAN) which has returned 2039K rows, scans several partitions(1-17) and in the fast running query the same table is accessed by global index 'PK_ADIOUNIV_IDUNIV'(INDEX UNIQUE SCAN) has returned 1 row, which doesnt run through all the partitions.<br> Index Range Scan obviously returns more rows than Index Unique Scan. Here in the Slow running plan Index Range Scan is influencing the Nested Loop(Cost 269).