VM
меня напрягает еще что запрос за 2 секунды отрабатывает со сброшенным кешем
Size: a a a
2020 July 25
VM
т.е. подозрительно быстро для моего железа, хотя может сжатие хорошее
VM
SELECT data FROM table AS s PREWHERE (s.project_id = 2) AND (s.time >= '2020-07-24 06:10:00') AND (s.time < '2020-07-25 06:10:00') AND (s.type != '') ORDER BY "duration" desc LIMIT 10
AZ
Я полагаю, замена PREWHERE на обычный WHERE не помогает?
VM
нет, было where изначально - это я уже мудрю
AZ
(в вашем случае должно «само» догадаться)
D
Vladimir Mihailenco
SELECT data FROM table AS s PREWHERE (s.project_id = 2) AND (s.time >= '2020-07-24 06:10:00') AND (s.time < '2020-07-25 06:10:00') AND (s.type != '') ORDER BY "duration" desc LIMIT 10
у вас order by есть, он будет читать все строки соответствующие условиям
сравните сколько считано с prewhere и where? лучше смотреть в трейс
сравните сколько считано с prewhere и where? лучше смотреть в трейс
AZ
К сожалению, у меня нет идей, кроме «вот так сложилось» (например, разбросаны значения для чтения по таблице, приходится читать много кусков, искать соотв строки в них, и выходит такой дикий перерасход по данным)
VM
Если заменить ORDER BY duration на ORDER BY колонка из ключа то начинает работать быстрее. Так должно быть или есть надежда как-то ускорить?
D
WAS AV
Добрый день
Есть одна таблица из 200М записей с движком ReplacingMergeTree
Зависает запросе select * from tabname limit 1, но если добавить любое условие, то отрабатывает.
Кто-то с таким сталкивался? Куда копать?
Есть одна таблица из 200М записей с движком ReplacingMergeTree
Зависает запросе select * from tabname limit 1, но если добавить любое условие, то отрабатывает.
Кто-то с таким сталкивался? Куда копать?
партов сколько в таблице? если очень много - было такое тоже...
VM
>у вас order by есть, он будет читать все строки
так и происходит - я надеялся он может сначала отфильтровать по ключу и не читать все данные - хотя быть 10-15%
так и происходит - я надеялся он может сначала отфильтровать по ключу и не читать все данные - хотя быть 10-15%
WA
партов сколько в таблице? если очень много - было такое тоже...
6463
VM
т.е. сначала отсортировать и прочитать только нужное количество строк отсортированных
D
Vladimir Mihailenco
>у вас order by есть, он будет читать все строки
так и происходит - я надеялся он может сначала отфильтровать по ключу и не читать все данные - хотя быть 10-15%
так и происходит - я надеялся он может сначала отфильтровать по ключу и не читать все данные - хотя быть 10-15%
ну и какие результаты с prewhere?
D
WAS AV
6463
а колонок тоже?
VM
>ну и какие результаты с prewhere?
то же самое - читает на 2 тысячи строк меньше - но это капля в море
то же самое - читает на 2 тысячи строк меньше - но это капля в море
VM
сейчас скину гист
VM
Т.е. сейчас мой вопрос такой - можно как-то ускорить запрос с ORDER BY duration? чтобы работал примерно так же как и ORDER BY project_id
VM
Еще заметил что оптимизация (MergingSortedTransform?) работает только если ORDER BY first_column_in_key . Если уже сортировать по 2ой колонке в ключе - то опять читает все данные. Так должно быть?