Clickhouse reads too many marks on large parts when query filter by PK about clickhouse

[UnamedRus]

, (num % 1000) + 1)

Bad locality of num values

You better find some value, so result of function intDiv(num, value) will return reasonable amount of partitions

[nickitat]

afaiu, the difference comes from the fact that we load all the marks for the given part regardless of how many granules we're going to read. thus when you had small parts and filtered all of them except one it worked better.
the supposed solution is to increase mark cache size. you also may increase index granularity, but it doesn't scale.

Any suggestions on splitting single parts into multiple

more granular partitioning or you could try keep parts size limited with max_bytes_to_merge_at_max_space_in_pool

[teckatlipoka]

, (num % 1000) + 1)

Bad locality of num values

You better find some value, so result of function intDiv(num, value) will return reasonable amount of partitions

Actually my table has only one value for num = 0. So it has only 1 partition per month. This is why original query should look at 1 partition only.