пока что мало строк, в десятках тысяч измеряется (не миллиарды, в общем)

????
так если у вас все только начинается, то вы в ETL добавьте колонку и  сохраните еще и  в UTC

у меня аж 4 или 5 колонок с временем ивента

придумывайте себе проблемы как комсомолец

стараюсь, как видите :)
просто привык, что подобное без проблем можно проворачивать "на лету" не меняя ничего в пайплайне, вот столкнулся с КХ, неоптимально пытаюсь использовать 😱

попробуем такой вариант, спасибо
просто ожидал, что есть вариант попроще, вроде конвертации "на лету"

toInt32(dt) ?

это не сделано в КХ потому что КХ по сути не умеет TZ в значениях, то что вы хотите не вписывается в КХ в тип DateTime.
Т.е. это планируется сделать при конвертации времени в строки.

TZ это сабатрибут типа DateTime (атрибут колонки)

теперь понятно становится, в чем проблема

ну в доке это по моему обсосано, я точно что-то такое писал, не помню только про DateTime или DateTime64

скорее всего так и есть, но как показывает практика, люди вроде меня все время детали упускают при чтении документации
сначала КАЗАЛОСЬ, что должно сработать, но по факту - ничего подобного 😁
в любом случае - спасибо за помощь и разъяснения

вот например toTimeZone ничего не конвертирует, просто меняет в метаданных типа в заголовке DateTime.Moscow на DateTime.Kiev
сами значения в как были UInt32 в секундах в UTC (unixtimestamp) так и остаются.
Но при рендеринге строки эти UInt32 конвертируются в другие строковые значения

Причем если клиент конвертирует время например в Atlantic/Canada, то вообще ничего не меняется.
DateTime.Moscow -> DateTime.Kiev -> Atlantic/Canada === DateTime.Moscow -> Atlantic/Canada

Вопрос на понимание, как работает "оптимизатор" в КликХаусе. Пусть ПК: id, date. Если я верно понимаю, то существует оптимизация, которая позволит запросу вида "select ... where id = :1 order by date desc limit 10" быть эффективно выполненным (некий аналог того, что называется index range scan descending в Оракле или scan backward в Постгресе), тем самым прочитав почти минимально необходимый объем данных. Собственно вопрос, существует ли такая оптимизация для не скалярного условия вида "id in (:1, :2, ...)"? И как это работает, типа очереди с приоритетом или..? Спасибо.

существует.

Какая очередь? о чем вы? Просто бежим по списку - перечислению и находим из первичного ключа список засечек, список засечек передается на следующий уровень пайплайна

а ну кстати в КХ не работает where id = :1 order by date desc
надо where id = :1 order by id, date desc
желательно where id = :1 order by id desc, date desc

для списка тоже самое select ... where id in (:1, :2, ...) order by id desc, date desc limit 10

это просто не доделано, и планов доделывать нет

Попытаюсь объяснить.
Если оптимизация для скаларного предиката есть, то напрашивается вывод -- разбить запрос с нескалярным предикатом на несколько заросов со скалярным, объединенных по Union all. Тем самым выбрать условно 10*n записей, а на последнем этапе уже отсортировать детерминированно и взять ровно 10. Очередь с приоритетом как раз решает такой паттерн.