во первых - вы путаете парт и партиция - это две разные вещи.
я так понял что у вас проблема в том при селектах из одной партиции, остальные не учитываются.
Но это так и должно быть. Сначала всегда идет отсечение партиций, потом уже на оставшихся данных мердж.
с этим надо жить и понимать, либо строить запросы типа d>date, либо как в других базах делать ключ партиционирования частью PK.

Спасибо, я ещё новенький просто , извиняюсь что путаюсь в терминологии. Решил что вы так сокращённо пишете тут.

Ну вот в этом и суть получается. Вы все верно поняли.replacemergetree работает верно, но не так как нудно. Есть ли более удобные решенеия, нежели переход на движок collapse?

Collapse ведь внутри патриции схлопнет данные по 1 и -1, а в результате за неактуальный месяц не покажет данные. Думаете это не поможет?

Это в какой версии так работает? В вашем случае все работает верно потому что поле d, по которому вы проводите партицирование не изменилось. Вставьте в d=12 второй транзакцией и постройте два запроса WHERE d=11 и WHERE d=12. Вы увидете одну и ту же запись в обоих резальтатах, только d у них будет отличаться. Ну и s разумеется.

>ClickHouse also automatically cuts off the partition data where the partitioning key is specified in the query.
https://clickhouse.tech/docs/en/engines/table-engines/mergetree-family/mergetree/

Я так понимаю и сужу по полученным данным, что это общее свойство для всех mergetree. Допустим у вас есть один товар с id=1, который был создан 15 июля - он попадает в партицию 15-го июня, затем этому же товару изменили дату создания на 15 августа. Когда вы будете искать список товаров созданных в июне, вы найдете товар с id = 1, когда вы будете искать товар созданный в августе найдете этот же товар. Потому что FINAL видит первичный ключ, по которому происходит секционирование и отрубает все остальные данные.

Если использовать collapsemergetree то данные следует обновлять так (насколько я понял)
insert into f values(1, 11, '1', 1)
insert into f values(1, 11, '1', -1)
insert into f values(1, 12, '2', 1)

Внутри партиции за дату 11 данные схлопнутся и не выведутся, внутри партиции 12 данные схлопнутся и выведутся. Это не так?

a) не делать партиций
b) делать по месяцам но запрашивать в виде d>myMonth
c) делать по группам ID

Если использовать collapsemergetree то данные следует обновлять так (насколько я понял)
insert into f values(1, 11, '1', 1)
insert into f values(1, 11, '1', -1)
insert into f values(1, 12, '2', 1)

Внутри партиции за дату 11 данные схлопнутся и не выведутся, внутри партиции 12 данные схлопнутся и выведутся. Это не так?

ну понятно, pushdows, pruning

select * from f final where identity(d)=toDate(11)

а) не подходит потому что слишком много данных для поиска (может индексирование выручит?)
б) тоже нельзя, потому что люди хотят видеть данные за последние 7 дней, а там и прошлый месяц может оказаться
в) слишком много партиций, опять же запросы долго будут выполнятся

а, вы про это, да, можно, но надо помнить что при вставке условно 10000 вам надо найти были ли все эти 10000 вставлены раньше, в какое время, итд, так как надо вставить в ту же колонку.
мне такой вариант вообще даже не представляется возможным. если вы ещё где нить не храните данные

не понял проблемы.
в select-ах ИД всегда указан? если да - вообще не проблема... сканьте все партиции (вон можно identity)

В селекте всегда есть дата создания. Без партиций 10 ГБ данных отфильтруется думаете? Но я попробую в любом случае.

а ID всегда есть? (не дата, ID, по которому у вас order by)

Нет, не всегда. А в WHERE - никогда.

SELECT toDate(created_at, 'Europe/Moscow') AS date, count() as data_count, sum(price) as price_sum
FROM offers_conversions FINAL
WHERE (created_at BETWEEN '2020-08-02 21:00:00' AND '2020-08-16 20:59:59')
GROUP BY date;