материализованное) для их объединения через union all. В исходных таблицах есть enum колонки с немного разными наборами. Имеет ли смысл их объединять, приведя прямо в запросе к типу LowCardinality(String), или разницы с просто toString не будет, если прямо в запросе к LowCardinality пытаться приводить?
Ну и аналогичный вопрос, если исходные колонки - это просто String, но известно, что уникальных значений немного. То есть кастить к enum не получится, ибо в исходных таблицах набор может меняться. Словари тоже пока не подходят, хочется уметь быстро генерить вьюхи без дополнительных сущностей.
Как я понимаю, LowCardinality экономит только диск и IOPS. Если все уже полняли в память, то разницы особой не должно быть, так что я бы не заморачивался и объединял все в простых String. Особенность с 5000 в приципе понятна, просили 5000 строк считать через max_block_size - вот и получили. Интересно как оно оптимизирует до 1000 в простых случаях с целыми числами.
Если в настоящей таблице LowCardinality, то оно же "поднимает" в память не строки, а словарик и работает с числами
Понятно что можно работать с числами когда нужно сделать group by, а обратный индекс поможет для сравнения числа в словаре со строковой константой. Но как сравнить строки в виде чисел в разных словарях или объединить два словаря (ваш случай) без превращения их в строки?
Обсуждают сегодня