SC
перед тестовыми запросами сбрасывал page cache?
Size: a a a
2021 January 09
SC
ну значит просто медленные запросы могли получится из-за того что нужных данных в памяти не было и пошли долгие чтения с диска
AS
и так 10 раз? подозрительно чтото
SC
во втором <Information> executeQuery: Read 483903165 rows, 31.43 GiB in 11.142873359 sec., 43427143 rows/sec., 2.82 GiB/sec.
тут видно что с диска больше читает. нужно больше инфы - схема таблицы, сами запросы
SC
причём разница по объёму прочитанного 30 раз
SC
и так 10 раз? подозрительно чтото
что на серверах? хдд? ссд/нвме?
AS
что на серверах? хдд? ссд/нвме?
nvme
SC
ну тогда странно, надо смотреть
AS
повторить очень легко, сделать таблицу с текстовым полем. и туда записать. одинаковое значение, и сравнить с WHERE string=‘’value’ и без этого.
SC
а, ну тут просто на сравнении строк тормозит похоже
SC
потому что надо все эти миллионы строк проверить, это не бесплатно
AS
что там проверять они все одинаковые
SC
а как ты узнаешь что они одинаковые, если не проверишь?
AS
и самое печальное я не могу это объяснить clickhouse. причем INDEX делает тольуо хуже
AS
у меня возникла фундаментальная проблема - как использовать низкокардинальную фильтрацию запросов. Я общего решения так и. не нашел
AS
все они тормозят, даже самый лучший вариант тормозит от 2 до 10 раз
SC
какие-нибудь ENUM использовать? uint8 всяко проще сравнивать чем string
AS
AS
спасибо ему