ведет к падению производительности запросов на сканирование (1.2 миллиона записей). Это как-то меняется внутри формат хранения данных?
если индексы не помогают, то меняйте order by, если он уже оптимален для основного кейса, но для второстепенных - нет и не получится, то юзайте проекции. https://clickhouse.tech/docs/ru/engines/table-engines/mergetree-family/mergetree/#projections
Для одних и тех же запросов и данных изменение гранулярности рушит производительность на сканирование. Т.е. с 800 QPS при гранулярности в 8192, до 64 при 1. Но данные те же и запросы те же.
Ну вам надо в 8 тысяч раз чаще читать, конечно будет медленно
Сканирование идет всей таблицы в любом случае, это фул скан. Гранулярность меняет как-то формат хранения данных?
данные отдельно, индексы отдельно, индексы сбоку и не влияют на хранение данных
Ну индексу может надо куда-то указывать, что распаковано и лежит отдельно. Просто мысли вслух.
то что вы описали называется проекции, а не индексы :)
Мне казалось primary key всегда используется, даже при seq scan, но возможно я не прав
Попробуйте send_logs_level = 'trace' и посмотреть что читает
Обсуждают сегодня