КХ никак не оптимизирует limit 99000000,2
Я вообще не знаю ни одно базы которая такое умеет.

Т.е. КХ можно наверное научить такой фокус с Enine=Log/MergeTree если там тупой select * from xxx limit 99000000,2 потому что мы знаем сколько строк в гранулах. Но этож вырожденный редкий случай и куча возни с учетом партиций и order by , сейчас нет пропуска партиций при оптимизации order by потому что выражение партиционирования может не совпадать с выражением сортировки таблицы

Уважаемые, а подскажите, есть ли в Европе SaaS для Clickhouse помимо yandex.cloud ?
Все что кроме РФ общем

может от Altinity

но чет я таки не нагуглю

Лондон, Франкфурт

а нет. Clickhouse coming soon https://www.alibabacloud.com/product/databases

ну скоро будет

нету

в общем мой комент был в сторону того, что если запрос возвращающий этот миллион супер сложный, то ложите его куда нибудь, и гоняйте пейджинг/сортинг/фильтеринг по нему

да я понял, просто ТС спрашивал КМК про банальный select * from order by PK limit 1000000000,10

и я не знаю какая БД такое умеет оптимизировать

Чем больше селектов делаю, тем больше становится время селекта.

да там вот эту фразу сложно "распарсить"

12 сентября будет доклад "Две низкоуровневые оптимизации, которые я сделал вчера": https://ya.cc/t/cIBI-3yECj5JF

Паджинацию нужно делать не так. Правильная паджинация — это WHERE id > наибольший_id_на_текущей_странице LIMIT 10. Skip-индексы для id так же помогут, если id не присутствует в ORDER BY ключе

Ну и вообще в принципе паджинация на 100500 страниц не нужна. 640 хватит всем.

Всем привет! А у кого-нибудь был опыт обновления кликхауса со старых версий ~18.* ?
Как себя чувствует репликация, если на шарде одна из реплик будет в старой версии, а вторая - в новой?

Еще видимо в старых версиях пакеты назывались как clickhouse-server-base и clickhouse-server-common, а при обновлении (https://clickhouse.tech/docs/ru/operations/update/) ставятся clickhouse-common-static и clickhouse-server. При этом старые остаются - насколько безопасно их ремувать (через dpkg -L видно, что у них есть общие директории)?

Репликация остановится на время работы разных версий на одном кластере. При этом SELECT будет работать. То есть, для rolling update подходит, но надолго оставлять не нужно.

Надо прочитать все пункты в changelog про обратно несовместимые изменения.

Если есть тестовая среда - проверьте обновление на ней.

Да, имена пакетов были изменены. Я не помню, насколько безопасно их удалять - можете и оставить просто так. Главное установить новые.

Понял, спасибо!

при обновлении на 19ую (19.4.5.35) версию все прошло гладко
но при обновлении на 20ую (20.8.2.3) кликхаус стал падать с ошибкой аттача таблицы из-за словарей:
<Error> Application: DB::Exception: external dictionary 'xxx' not found: default expression and column type are incompatible.: Cannot attach table ...
Почитал нарушения обратной совместимости, но про словари там вроде не было