foo LIMIT 50 на 75к (2МБ) строк ставит весь КХ колом, но после запроса даже KILL QUERY не работает.
Вопрос такой - как сделать, чтобы по таймауту запрос килялся сам, а не висел в system.processes? max_execution_time=20 и cancel_http_readonly_queries_on_client_close=1 ничего не дают независимо от типа подключения, это разве нормально?
это нормально. В контексте запроса выставляется флаг killed, при переключении блоков (65k строк), флаг проверяется и выходим из выполнения. SELECT * -- полей сколько? Каждое поле аллоцирует 1MB буфер для декомпрессии, если полей много и max_threads=16 например то все они будут аллоцировать память, возможно очень долго.
прежде чем разбираться с причинами, хотелось бы простейшего - простой таймаут на запрос, чтобы КХ отвисал, но видимо это невозможно, что очень странно, фича то базовая
так это нихрена не просто и вообще все работает абсолютно не так как вы думаете, поэтому и нет.
ясно понятно, насчет "это нормально", я имел ввиду, что в серьезном, продакшн риди софте, есть опции, они задокументированы, но тупо не работают, и видимо никогда не работали
все работает, просто не так как вы думаете.
max_execution_time Максимальное время выполнения запроса в секундах. На данный момент не проверяется при одной из стадий сортировки а также при слиянии и финализации агрегатных функций.
Я это читал, спасибо что еще раз напомнили про этот момент, проверил - запрос без ORDER BY some_field DESC действительно быстро работает, а SELECT COUNT(*) FROM foo так же все вешает нафиг, теперь хотябы стало понятно на какой стадии. Но претензии к cancel_http_readonly_queries_on_client_close все еще остаются.
эм, `SELECT COUNT(*) FROM foo` не читает таблицу , там сделан хак, он считает по структуре в памяти, parts, в parts есть rows.
Обсуждают сегодня