Contagem lenta em mesa vazia inexplicável

Minha atualização incremental de visualização materializada está começando a ficar cada vez mais lenta. Todos os dias há milhões de novos registros. Portanto, há muitas exclusões na tabela de log mv. Após investigação, vejo um sql específico demorando muito, o que pode levar à causa raiz. A seguir está um dos SQLs em execução como parte da atualização mv:

SQL> select dmltype$$, max(snaptime$$) from "S"."MLOG$_TABLE_202210" group by dmltype$$;

no rows selected

Elapsed: 00:00:12.68

Statistics
----------------------------------------------------------
      7  recursive calls
      0  db block gets
     678822  consistent gets
     678789  physical reads
      0  redo size
    438  bytes sent via SQL*Net to client
     41  bytes received via SQL*Net from client
      1  SQL*Net roundtrips to/from client
      0  sorts (memory)
      0  sorts (disk)
      0  rows processed

Como você pode ver, uma contagem nesta tabela de log mv vazia levou 12s! (temos muitos assim). O motivo são as altas leituras físicas. As estatísticas estão bloqueadas no propósito (conforme recomendação do oráculo)

SQL> select NUM_ROWS,BLOCKS,EMPTY_BLOCKS,AVG_SPACE_FREELIST_BLOCKS,LAST_ANALYZED,STATTYPE_LOCKED,STALE_STATS 
     from dba_tab_statistics 
     where table_name='MLOG$_TABLE_202210';
  NUM_ROWS     BLOCKS EMPTY_BLOCKS AVG_SPACE_FREELIST_BLOCKS LAST_ANAL STATT STALE_S
---------- ---------- ------------ ------------------------- --------- ----- -------
         0          0            0                         0 14-NOV-22 ALL   YES


SQL> SELECT EXTENTS, blocks, bytes
FROM dba_segments
WHERE SEGMENT_NAME = 'MLOG$_TABLE_202210';

  EXTENTS    BLOCKS     BYTES
---------- ---------- ---------- 
        18      384    3145728

Então se a tabela não estiver em SGA ela passa por cima de todos os blocos que está alto devido ao HWM das muitas exclusões. Como tudo isso é atualização de mv - se eu executar truncar, isso interromperá os MVs.

Eu apreciaria algumas outras sugestões.