АЮ
если только id то можно без фрагмента обойтись
where([q], q.id in ^lol_ids)Работает на порядки медленнее. Я поэтому и хочу переписать.
Size: a a a
2020 December 23
АЮ
Особенно, если айдишников много.
NM
Особенно, если айдишников много.
А почему там именно список айдишников нужен? Нет к ним join таблицы?
AD
Работает на порядки медленнее. Я поэтому и хочу переписать.
пункт joining with fragments https://hexdocs.pm/ecto/Ecto.Query.html#join/5
NM
Километровый список айдишников в запросе выглядит как антипаттерн. Поправьте, если не права
АЮ
А почему там именно список айдишников нужен? Нет к ним join таблицы?
Так работают прелоады, если их прямо в квери не пропихивать.
ML
Километровый список айдишников в запросе выглядит как антипаттерн. Поправьте, если не права
километровый — это сколько? 200 или 200 тыс?
АЮ
И их удобнее подгрузить отдельно, если только ради них нужно юзать лефт джойны.
NM
И их удобнее подгрузить отдельно, если только ради них нужно юзать лефт джойны.
Ок
PG
пункт joining with fragments https://hexdocs.pm/ecto/Ecto.Query.html#join/5
слева от заголовка есть якорь
https://hexdocs.pm/ecto/Ecto.Query.html#join/5-joining-with-fragments
https://hexdocs.pm/ecto/Ecto.Query.html#join/5-joining-with-fragments
АЮ
пункт joining with fragments https://hexdocs.pm/ecto/Ecto.Query.html#join/5
Хм. Видимо, пропустил этот пункт. Спасибо.
V
Работает на порядки медленнее. Я поэтому и хочу переписать.
На каком объёме бенчмаркал?
АЮ
V
На каком объёме бенчмаркал?
Там ещё пара джоинов. Если не брать фильтрацию по айдишникам (их было 48), то там примерно 3к записей с копейками.
V
where id in (<ids_list>) выглядит как самый быстрый вариант из возможных, я использовал его много раз в разных вариациях и не имел проблем со скоростью.То что ты пишешь о тормозах с этим условием, тем более "на порядки медленнее" - звучит как минимум странно. 3к строк всего и 48 айдишников - в принципе очень маленькое количество для проблем с производительностью
АЮ
V
where id in (<ids_list>) выглядит как самый быстрый вариант из возможных, я использовал его много раз в разных вариациях и не имел проблем со скоростью.То что ты пишешь о тормозах с этим условием, тем более "на порядки медленнее" - звучит как минимум странно. 3к строк всего и 48 айдишников - в принципе очень маленькое количество для проблем с производительностью
Ну смотри.
АЮ
АЮ
AB
Ну смотри.
я не большой специалист, но смотрю в планы и не очень уверен, что стал полагаться на такое поведение оптимизатора.
(и как следствие этого, наверное, денормализовал бы это всё к чертям)
(и как следствие этого, наверное, денормализовал бы это всё к чертям)
V
Не могу понять что за Nested Loop. Вроде бы постгрес рисует explain с отступами?
V
Видимо, в первом случае постгрес строит декартово произведение по всем строкам трёх таблиц, а потом фильтрует, и фильтрация по айдишникам происходит не в первую очередь.