спасибо

чего стопать? он у вас не запускается

запускается. Он работает и в процессе работы периодически сыпет такие сообщения

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

может стоит грейдануться на 20.3 тогда, лтс все таки и процессоры еще можно выключить.

А что там в 20.3 ?

Это мы в первый раз решили апнуть и наломали кучу дров

А почему вообще даунгрейднулись, что то сломалось?

Самый последний ЛТС на данный момент, и не так далеко от 20.4 так что проблем от даунгрейда должно быть меньше. но эт все имхо.

Мы были на 19.15.3.6. Все работало нормально
Потом мы решили использовать RBAC и создание словарей запросами. Для этого решили апнуться и выбрали последнюю стейбл версию
У нас все посыпалось и откатились обратно.
Судя по всему, сломали то что уже сломалось еще раз

А вот в 20.5 ускорение файнал и еще пара интересных фич. Тоже хотелось бы заполучить это

прод или тестинг?

ну мы пока не в проде, но это был наш препрод, на который уже смотрели будущие клиенты
ну, оно работает, но не все. И сообщения об ошибках в логах

Ну тут все зависит от того, насколько у вас есть силы разбираться в ошибках, но емнип ничего вроде бы не должно было быть прям сломано в новых версиях относительно старых. Были некоторые изменения, но старое поведение можно включить в настройках(например алиасы с джойнами)

впрочем я обновлялся только с 19.17

Добрый день, коллеги! Приветствую особенно гуру, что не боты. Не могли бы вы помочь слепцу в поисках истинны среди всяческого индексированного добра.
Что есть: огромная реплицированная таблица с 10 млрд линий и около 100 колонок. Есть партицирование ее по дате и одному инту(назовем его комит_ид), сортировка по двум стрингам и еще одному инту. Первичный ключ не указан. Сделанно специально, чтобы оптимизировать некоторые запросы типа SELECT. Теперь появились новые запросы в соторые еще добавились сравнение на равенство по колонки типа ЮИнт64 (который некий хэш) и один Инт8 у которого 2 значения : +1 или -1. По ключу сортировки и партиции тоже сравнение на равенство.
Проблема: впечатление, что КХ сканирует все, так как запрос производится в течение 20 с. Попытался добавить минмакс индекс и блум-филтер. Переоптимизировал таблицу. Время не улучшилось, а иногда в некоторых вариантах ухудшилось.
Вопрос: у кого естль луч света в царстве индексирования данных и оптимизации? Заранее благодарен

единственный случай когда вам помогут скип индексы это когда у вас есть какая то локальность данных(те что учавствуют в скип индексе), с учетом ORDER BY таблицы

я бот, но имхо нету. если ваш хеш не привязан к сортировке (локальность выше) скип индексы в мусорку.

рекомендую попробовать добавить ваш хеш в конец вашей сортировки, или перед комит-ид может помочь и проверить на саб-сете данных

ещё если у вас ожидается ответ от одной/нескольких строк по хешу попробуйте prewhere. нам помогало