D
Vladimir Mihailenco
во 2ом посте пример запроса
Коррелированные подзапросы не поддерживаются
Size: a a a
2020 July 25
VM
Это рекомендованный вариант подобной оптимизации в КХ. Непонятно, что вы ожидаете в своем тикете - чтобы он магически трансформировал запрос? Кх не сможет сам догадаться плюс гарантий нет
ну из SQL мира это стандартное поведение - магией это сложно назвать
я ожидаю что у кликхаус есть примерно оценка сколько надо прочитать и включать эту оптимизацию
я ожидаю что у кликхаус есть примерно оценка сколько надо прочитать и включать эту оптимизацию
D
Vladimir Mihailenco
ну из SQL мира это стандартное поведение - магией это сложно назвать
я ожидаю что у кликхаус есть примерно оценка сколько надо прочитать и включать эту оптимизацию
я ожидаю что у кликхаус есть примерно оценка сколько надо прочитать и включать эту оптимизацию
КХ не совсем sql )
VM
я понимаю, но полагаю что так сделано потому что для маленьких колонок так быстрее
для больших быстрее по-другому
можно при желании это как-то переключать
для больших быстрее по-другому
можно при желании это как-то переключать
D
Тут дело в том, что я вывел содержимое ин() эвристикой полагаясь на ваш ключ и то что он скорее всено достаточно уникален. Ключа может не быть. Он может быть настолько неуникальным что запрос будет в 2 раза медленнее по итогу. Но вообще вы правы, специфичные случаи можно предрассчитать, вот только какой это % от общих случаев?
VM
не знаю зачем так сделано и как это сделано
может действительно мое предложение выглядит как магия
просто так работает постгрес и mysql и ожидаешь что-то подобное от кликхауса
может действительно мое предложение выглядит как магия
просто так работает постгрес и mysql и ожидаешь что-то подобное от кликхауса
D
Vladimir Mihailenco
не знаю зачем так сделано и как это сделано
может действительно мое предложение выглядит как магия
просто так работает постгрес и mysql и ожидаешь что-то подобное от кликхауса
может действительно мое предложение выглядит как магия
просто так работает постгрес и mysql и ожидаешь что-то подобное от кликхауса
А можно гист из пг или mysql? Кмк они тоже так не работают если нет доп индекса на поле в order by
VM
ну проблема что кликхаус читает всю колонку в милион строк даже если надо только 10
D
Vladimir Mihailenco
ну проблема что кликхаус читает всю колонку в милион строк даже если надо только 10
А пг/mysql читает все колонки на весь миллион строк...
VM
не, если колонка большая то постгрес хранит данные отдельно
VM
и прочитает тольно нужные
D
Vladimir Mihailenco
не, если колонка большая то постгрес хранит данные отдельно
А, вы про текст /лоб... Ну кх этого не умеет, как и другие колоночные базы
VM
ну тут ведь дело что кликхаус все умеет и может - и будет быстрее
вопрос только написать логику под эту оптимизацию
вопрос только написать логику под эту оптимизацию
BB
Понятное дело что нет, но вдруг - есть ли способ оптимизировать поиск %value%
D
Понятное дело что нет, но вдруг - есть ли способ оптимизировать поиск %value%
Только Tokenbf skip index если value встретится только в нескольких строках?
https://clickhouse.tech/docs/en/engines/table-engines/mergetree-family/mergetree/#functions-support
https://clickhouse.tech/docs/en/engines/table-engines/mergetree-family/mergetree/#functions-support
DT
Понятное дело что нет, но вдруг - есть ли способ оптимизировать поиск %value%
сделать отдельную таблицу и ее использовать как реверс индекс?
DT
Только % в начале мешает
BB
сделать отдельную таблицу и ее использовать как реверс индекс?
Реверс спасет от %value
BB
Только Tokenbf skip index если value встретится только в нескольких строках?
https://clickhouse.tech/docs/en/engines/table-engines/mergetree-family/mergetree/#functions-support
https://clickhouse.tech/docs/en/engines/table-engines/mergetree-family/mergetree/#functions-support
Ну т.е делать pk на value и вешать ещё скип индекс ?