Выясняется, что в Many-to-one почти всегда выигрывает subquery, также как и в Many-to-many. Разница на миллионе записей почти в два раза. Получаю в общем на миллионе записей такие результаты:
Many-to-many
Joined ±12sec
Selectin ±7sec
Subquery ±5sec
Core ±8 ms
Как вы думаете, насколько вообще адекватны результаты?
а ты в оригинальной выборке сделай 100500 фильтров и посмотри =)
То есть sub query лучше не использовать, если сложная where конструкция?
subquery лучше не использовать если ты не уверен на 100% что он тебе действительно нужн
Хм, вот на основе этих замеров что-то мне кажется что задумываться надо над использованием чего-то кроме сабквери)
у тебя в оригинальном запросе что было?
Родитель и множество дочерних, у одного дочернего несколько родителей. Получаю список дочерних у родителя через relationship с разными стратегиями
subquery же исполняет исходный запрос два раза. Так что если у тебя сам по себе запрос медленный, то subquery будет медленее, нежели selectin
Почему у тебя core в сотни раз быстрее orm?
только сейчас разглядел 7 сек и 5 сек. Это что за числа аткие большие
Потому что замер берет еще маппинг объектов, да. Core здесь я просто сравнивал для себя, основное сравнение между стратегиями ВМЕСТЕ С маппером орм.
Из-за орм маппера
Стратегии создают разные запросы, а ты сравниваешь не скорость этих запросов, а скорость работы маппинга
вообще не очень понятно насколько эффективно делать серии замеров, ведь получается что на первых запросах всё будет идти как обычно, а дальше у базы будет врубаться кеш и вот хз можно ли в sqlite его вырубить
Обсуждают сегодня