RK
Не пробовал, прямо сейчас нет возможности проверить
Size: a a a
2021 February 12
DC
КХ выделяет память (буфера по несколько мегабайт) в куче потоков на каждую колонку
RK
Хм. Но вне зависимости от того, какие колонки указаны в SELECT, ему ведь нужно прочесть только те, что в WHERE + в OrderBY. На этапе фильтрации. Это 3 колонки
RK
Не так?
DC
Хм. Но вне зависимости от того, какие колонки указаны в SELECT, ему ведь нужно прочесть только те, что в WHERE + в OrderBY. На этапе фильтрации. Это 3 колонки
вы просите SELECT *
чтобы распаковать содержимое 160 .bin файлов, выделяется 160*10 или на *32 (потоков) буферов по 1МБ , получается 160*10МБ
чтобы распаковать содержимое 160 .bin файлов, выделяется 160*10 или на *32 (потоков) буферов по 1МБ , получается 160*10МБ
DC
where и order by тут вообще еще не стояли
RK
Подождите. Разве фаза извлечения колонок, указанных в SELECT, начинается не после того, как фазы фильтрации и сортировки завершены? Если б это было так, то для извлечения 250 полных записей не нужно 20ГБ RAM 🙂
DC
Подождите. Разве фаза извлечения колонок, указанных в SELECT, начинается не после того, как фазы фильтрации и сортировки завершены? Если б это было так, то для извлечения 250 полных записей не нужно 20ГБ RAM 🙂
эм, вы там 1972 как живете? стримы у нас, все одноврерменно
RK
Ну и потребление памяти не как в 1972
RK
Ок, я понял
DC
Ок, я понял
max_threads=1, max_block_size=512
D
кстати да, было бы неплохо добавить фичу типа prewhere в order by при наличии лимит и отсутствии group by
т.е. пайплайн типа prewhere cols -> where + orderby cols -> select cols
т.е. пайплайн типа prewhere cols -> where + orderby cols -> select cols
D
все таки частый случай с этой вашей пагинацией
DC
кстати да, было бы неплохо добавить фичу типа prewhere в order by при наличии лимит и отсутствии group by
т.е. пайплайн типа prewhere cols -> where + orderby cols -> select cols
т.е. пайплайн типа prewhere cols -> where + orderby cols -> select cols
есть уже 2 FR о том что найти сначала марки order by limit а потом в них заходить
DC
просто КХ не для этого, удивительно что optimize_in_order вообще сделали
DC
коллеги, КХ сервер начал потреблять много памяти. при этом активных запросов очень мало. как понять, куда уходит память? версия
20.8.4.11как / чем вы проверяете? обновитесь до нормальной 20.8.12 ... что-то
RK
вы просите SELECT *
чтобы распаковать содержимое 160 .bin файлов, выделяется 160*10 или на *32 (потоков) буферов по 1МБ , получается 160*10МБ
чтобы распаковать содержимое 160 .bin файлов, выделяется 160*10 или на *32 (потоков) буферов по 1МБ , получается 160*10МБ
Окей. 160 МБ * 32 потока = 5 ГБ. Запрос потребляет порядка 20 ГБ. Для чего остальные 15?
DC
Окей. 160 МБ * 32 потока = 5 ГБ. Запрос потребляет порядка 20 ГБ. Для чего остальные 15?
это на чай
DC
set send_logs_level = 'trace'; в студию
DC
добрый день всем. Подскажите, пожалуйста, возможно кто-то сталкивался с вопросом загрузки данных из существующей таблицы Clickhouse на движке MergeTree() в существующую на том же движке, но с другим ключом сортировки данных. Исходная таблица содержит порядка 14 миллиардов строк (1 строка - это некий 1 ивент). Есть ли проблемы, связанные с выполнением такого запроса insert select? И насколько это ресурсозатратная операция в плане потребления оперативной памяти?
зависит от кол-ва колонок (ширины строки) , если 5 полей UIn64 то 14млрд это фигня, если 700 полей общей шириной 5 кб, то это часов 12 может переливаться