ALTER DELETE with skip index on where clause not longer pruning parts about clickhouse

[UnamedRus]

After I upgraded from 23.12 to 24.5, the same mutation is rewriting every part of the table, like if no parts pruning based on the filter happens anymore. This is a total blocker for us as delete mutations are made unusable by this new behaviour.

Technically, it always worked in such way.
Maybe, this degradation have other reason/explanation.
#59225 (comment)

[arnaudbriche]

When I looked in the system.part_log table, I observed that prior to 2024.3, most entries generated by the mutation had read_rows = 0, while after the upgrade the number was never 0 anymore.

[arnaudbriche]

I found out in previous issues that parts that where pruned by the where clause are supposed to be renamed only.
This behaviour is consistent with the previous perf characteristics I used to observe for this mutation.

#12188

[SaltTan]

What about SELECTs? Is the index used?

explain indexes=1
SELECT count() from evm_blocks_ethereum_mainnet  
WHERE block_number > <SOME_RECENT_BLOCK_NUMBER>

[arnaudbriche]

Unfortunately I cannot test your query by now because I downgraded the nodes to 24.2.

But the following query ran in low milliseconds so I am confident that the index is actually used.

select
    max(block_number)
from evm_blocks_ethereum_mainnet
settings max_threads=1