таблице разделены на 95 партиций таким образом: PARTITION BY user_id % 95. user_id - это поле Int32. Явно поле "partition_id" у меня не задано.
Когда я добавляю в запрос условие user_id % 95 = 1 - видно, что запрос в партицию попал. Когда меняю условие на user_id % 95 IN (1, 2, 3) то запрос в партиции не попадает. С расширенным логированием пишет, что при условии "=" запрос попадает в одну партицию, при "IN" (даже если "= 22" поменять на "IN (22)") запрос выгребает сразу 50 партиций. И точно такое же большое количество партиций выгребается, если вообще не ставить условие партиционирования. Вопрос: есть ли способ попасть в несколько партиций каким-то условием или надежней будет перезалить таблицу с явно заданным ключем партиционирования?
Создайте issue в github'e
Использование partition pruning в качестве суррогата индекса не является рекомендованной техникой. Вы точно уверены что без этого никак не обойтись? Вы точно учли все негативные моменты этого подхода во всем пайплайне from ingest to backup типа черезмерных мерджей?
https://github.com/ClickHouse/ClickHouse/issues/36759#issuecomment-1112825383
Спасибо, а можно где-то про негативные моменты прочитать инфу? И что значит "Использование partition pruning в качестве суррогата индекса"? Имеется в виду в принципе задание партиционирования таблицы НЕ через Date или попытка обращение к нужной партиции через функцию?
пишите через OR и все будет хорошо
Обсуждают сегодня