D
это же полезный жор
Size: a a a
2020 September 18
l
Еще в относительно новых версия впилили штуку, что если ты делаешь JOIN об Dictionary таблицу, то оно там хитро преобразуется(возможно даже в dictGet). но оно не считается как за настоящий JOIN, те не создается очередной подзапрос
EP
привет о гуру кликхауса, ткните плз носом в место конфига, где отключить system_querry_logs или ограничить размер этой таблицы, со временем начала занимать очень много места
D
Evgen Pr
привет о гуру кликхауса, ткните плз носом в место конфига, где отключить system_querry_logs или ограничить размер этой таблицы, со временем начала занимать очень много места
EP
18.12.17 вот такая версия
D
Evgen Pr
18.12.17 вот такая версия
это к олдфагам, они вот вот проснутся
НЧ
Подскажите, такой запрос выполняется с ошибкой, это так и задумано?
НЧ
with arrayMap(x -> trimBoth(x), splitByChar(',', ' 1 ,2')) as ff
select *
from (
select arrayJoin(arr) as tt from (
select ['1', '2', '3'] arr
)
)
where tt in ff
select *
from (
select arrayJoin(arr) as tt from (
select ['1', '2', '3'] arr
)
)
where tt in ff
НЧ
Code: 36, e.displayText() = DB::Exception: Element of set in IN, VALUES or LIMIT is not a constant expression (result column not found): arrayMap(lambda(tuple(x), trimBoth(x)), splitByChar(',', ' 1 ,2')) (version 20.7.2.30 (official build))
НЧ
Суть в убирании пробелов в фильтрующем массиве
D
Николай Чернов
with arrayMap(x -> trimBoth(x), splitByChar(',', ' 1 ,2')) as ff
select *
from (
select arrayJoin(arr) as tt from (
select ['1', '2', '3'] arr
)
)
where tt in ff
select *
from (
select arrayJoin(arr) as tt from (
select ['1', '2', '3'] arr
)
)
where tt in ff
use the "has", Luke
with arrayMap(x -> trimBoth(x), splitByChar(',', ' 1 ,2')) as ff
select *
from (
select arrayJoin(arr) as tt from (
select ['1', '2', '3'] arr
)
)
where has(ff, tt) ;НЧ
о! благодарствую!
SM
Хаюшки. А есть какой то вариант для определенного юзера запретить делать запросы без указания определенного поля в WHERE?
Мы храним логи, и часто люди забывают указывать WHERE timestamp > today(), например - и CH пытается выгрузить логи за весь период - а это десятки ТБ.
Мы храним логи, и часто люди забывают указывать WHERE timestamp > today(), например - и CH пытается выгрузить логи за весь период - а это десятки ТБ.
D
Хаюшки. А есть какой то вариант для определенного юзера запретить делать запросы без указания определенного поля в WHERE?
Мы храним логи, и часто люди забывают указывать WHERE timestamp > today(), например - и CH пытается выгрузить логи за весь период - а это десятки ТБ.
Мы храним логи, и часто люди забывают указывать WHERE timestamp > today(), например - и CH пытается выгрузить логи за весь период - а это десятки ТБ.
там где-то был лимит на количество рам для запроса/сессии/юзера
SM
да, но у меня есть запросы, который выгружают инфы всего ничего, но потом пытаются ее отсортировать - и там CPU начинает бесконечно расти.
max_bytes_to_sort вроде тоже выставил, только это и спасает, но лучше было дать возможность писать запросы затрагивающий данные только за определенный период.
max_bytes_to_sort вроде тоже выставил, только это и спасает, но лучше было дать возможность писать запросы затрагивающий данные только за определенный период.
PB
Хаюшки. А есть какой то вариант для определенного юзера запретить делать запросы без указания определенного поля в WHERE?
Мы храним логи, и часто люди забывают указывать WHERE timestamp > today(), например - и CH пытается выгрузить логи за весь период - а это десятки ТБ.
Мы храним логи, и часто люди забывают указывать WHERE timestamp > today(), например - и CH пытается выгрузить логи за весь период - а это десятки ТБ.
такой возможности нет, но можно попробовать следующий костыль:
прикинуть, сколько исполняется "нормальный" запрос, и "ненормальный", выбрать какой-то разумный лимит по времени выполнения и установить "max_execution_time". установить "timeout_before_checking_execution_speed", отличный от 0. В таком случае, через "timeout_before_checking_execution_speed" КХ прикинет, сколько будет выполняться запрос, и если он не укладывается в "max_execution_time", то будет остановлен с type=4 и соответствующим эксепшеном
прикинуть, сколько исполняется "нормальный" запрос, и "ненормальный", выбрать какой-то разумный лимит по времени выполнения и установить "max_execution_time". установить "timeout_before_checking_execution_speed", отличный от 0. В таком случае, через "timeout_before_checking_execution_speed" КХ прикинет, сколько будет выполняться запрос, и если он не укладывается в "max_execution_time", то будет остановлен с type=4 и соответствующим эксепшеном
SM
у меня стоит max_execution_time в 5 мин, но я вижу запросы и дольше.
Наверное, потому что дефолтный timeout_before_checking_execution_speed у меня 0
Наверное, потому что дефолтный timeout_before_checking_execution_speed у меня 0
PB
у меня стоит max_execution_time в 5 мин, но я вижу запросы и дольше.
Наверное, потому что дефолтный timeout_before_checking_execution_speed у меня 0
Наверное, потому что дефолтный timeout_before_checking_execution_speed у меня 0
значит не применяется. в таблице system.query_log смотрите, какие настройки были использованы для каждого конкретного запроса
DC
Хаюшки. А есть какой то вариант для определенного юзера запретить делать запросы без указания определенного поля в WHERE?
Мы храним логи, и часто люди забывают указывать WHERE timestamp > today(), например - и CH пытается выгрузить логи за весь период - а это десятки ТБ.
Мы храним логи, и часто люди забывают указывать WHERE timestamp > today(), например - и CH пытается выгрузить логи за весь период - а это десятки ТБ.
force_index_by_date
force_primary_key
force_primary_key
SC
можно ещё ограничить объём макс чтения с диска