WHERE id NOT IN (тысячи записей из подзапроса) выполняется ну очень долго. Есть ли какой-нибудь волшебный способ сделать быстрее, не меняя логики запроса?
@komar Ты можешь попробовать сделать WHERE EXISTS (подзапрос WHERE главная колонка != id) в надежде, что по главной колонке построится индекс и всё будет летать. Ну, или вынести-таки в отдельную таблицу.
@minoru А что индекс? У меня 100% CPU сжирается на сраном сравнении каждого айдишника с миллионом вариантов. Я вообще таки думаю, что без изменения логики не обойтись, но вдруг я про что забыл.
@komar Ну, индекс даёт возможность быстро взять запись с нужным значением поля. Если глянуть в индекс, а там для такого значения записи нет — значит, id NOT IN (подзапрос) == true. Так же ведь?
@komar > сравнении каждого айдишника с миллионом вариантов.
```where id in (``` был заоптимизирован так не делать например
алсо возможно можно прерассчитать эту хуйню раз и навсегда
That's because the index is not really helpful for that kind of query, so the database has to do a full table scan. If the query is (for some reason) slower than a simple "SELECT * FROM TABLE", do that instead and filter the unwanted IDs in the program.
@krkm Логика именно такая: выбрать все, за исключением вот этого. Проблема в том, что «вот этого» дохера, и все CPU уходит на тупое сравнение. Сейчас доделаю вариант с временной таблицей и индексом и отпишусь, помогло чи нет.
@komar не знаю что за говно этот ваш SQL но я б сделал из множества ID "за исключением вот этого" поебень типа sparse array из bool-ов и выводил бы все это говно
@komar В моём понимании планировщик мог бы и догадаться, что сейчас придётся в результатах подзапроса много раз рыться, и сразу вынести его во временную таблицу и построить индекс.
Временная таблица с индексом по id?
@komar Гм, я что-то неправильное придумал, извини.
@komar Ты можешь попробовать сделать WHERE EXISTS (подзапрос WHERE главная колонка != id) в надежде, что по главной колонке построится индекс и всё будет летать. Ну, или вынести-таки в отдельную таблицу.
@minoru Ой, только я тебе логику сломал.
@komar Ну, индекс даёт возможность быстро взять запись с нужным значением поля. Если глянуть в индекс, а там для такого значения записи нет — значит,
id NOT IN (подзапрос)== true. Так же ведь?@komar То есть таки не оптимизировали NOT IN, вопреки утверждениям анонимуса :( Ты на ANALYZE EXPLAIN смотрел, кстати? Там правда всё грустно?
@komar В моём понимании планировщик мог бы и догадаться, что сейчас придётся в результатах подзапроса много раз рыться, и сразу вынести его во временную таблицу и построить индекс.
@komar Круто! И что, оно быстрее твоего предыдущего решения?