Ну это уже пофикшено в 20.8

суть в том, что кх читает по одной последней грануле для левых партов

ну не знаю, вы отпишитесь, пуская с деталями повисит, потом с тесткейсами закроется

так прунинга и нет вообще, у вас все из индекса и по индексу конечно надо читать +одну гранулу.
это вообще не кейс DJ

Selected 31 parts by date,

Selected 4 parts by date,

вы попробуйте where toDate(ts)=toDate('2020-09-24');

Ну, что бы не читать последнюю гранулу же давно было сделана специальная замыкающая гранула.

а там у вас mrk2 ? я не помню есть ли в индексе замыкающее значение или оно только марках.
но проблема хуже. У вас вообще "читается" 31 парт вместо 4. Партишен прунинга и нет совсем

Это прям свежая тестовая залитая таблица, думаю должна быть mrk2

попробуйте еще PARTITION BY toYYYYMMDD(ts)
и потом тоже самое условие что у вас было toDate(ts)='2020-09-24'

и смортеть на Selected 4 parts by date

а хотя toYYYYMMDD ничего не изменит. Select не знает про toYYYYMMDD

Убрал из ORDER BY ts
where toDate(ts)=toDate('2020-09-24');

на моей таблице, хоть она и должна быть похожа сейчас на пример DJ
делает фулл скан
```
CREATE TABLE part_prunning_test
(
   ts DateTime,
   dt Date DEFAULT toDate(ts),
   db_time DateTime DEFAULT ts
)
ENGINE = MergeTree()
PARTITION BY toDate(ts)
ORDER BY tuple()
SETTINGS index_granularity = 8192

INSERT INTO part_prunning_test(ts) SELECT toDateTime('2020-09-10 00:00:00') + INTERVAL number SECOND FROM numbers(3000000);


select count() from part_prunning_test where toDate(ts)='2020-09-24';
1 rows in set. Elapsed: 0.369 sec. Processed 2.97 million rows, 11.88 MB (8.04 million rows/s., 32.17 MB/s.)
select count() from part_prunning_test where toDate(ts)=toDate('2020-09-24');
1 rows in set. Elapsed: 0.370 sec. Processed 2.97 million rows, 11.88 MB (8.02 million rows/s., 32.10 MB/s.)
```
Если заменить
toDate на toYYYYMMDD результат такой же

Понял в чем косяк у меня с примером DJ, нужно было OPTIMIZE FINAL сделать, тогда в 20.7 не работает

Щас обновился на 20.9.
select count() from part_prunning_test where toDate(ts)='2020-09-24';
Selected 1 parts by date, 1 parts by key, 11 marks by primary key, 11 marks to read from 1

И после  OPTIMIZE FINAL работает корректно

>упс, я не на ту  таблицу посмотрел.

т.е. починили частично в 20.7? )

Нет, просто у меня каждый кусочек инсерта приземлился в свой парт и в каждом парте было только одно значение

поэтому и работало

а вот уже в 20.8 починено честно

а, у вас был в каждом партишне по одному парту? так в моем примере же разные комбинации