быстрее будет
ну я это и спрашиваю, если порядок условий имеет значение в зависимости от сложности)
Хм. Каких 🤔
По идее, влияет на то, будет использоваться составной индекс (если он есть) или нет. Или я уже туплю под вечер
вроде порядок в where ни на что не влияет )
Этому как раз пофиг id1 = x and Id= Y или наоборот.
На join влияет если хз много
разве? неужели geqo опирается на порядок? Можно ссылку?
Посмотрите на описание его и прочих параметров Конечно влияет
ну как пример SELECT * FROM users WHERE "поиск по индексу" AND "поиск без индекса" и наоборот ... WHERE "поиск без индекса" AND "поиск по индексу" есть ли разница в скорости
Я же написал, только при наличии join
увидел, спасибо)
если индекс выбирает тот же, разницы скорости нет но. предсказать какой индекс будет использовать для таких условий невозможно
посмотрел на описание и ничего подобного не увидел
geqo_threshold не?
не, это лимит настройки. Я думал вы про сам geqo алгоритм
Так и алгоритмы не жадные до бесконечности
это немного не то, согласитесь. Порог, после которого включается geqo и порядок в where - ну такое
Код смотреть не буду, 14 версии, но практические тесты показывают, что выбор алгоритма зависит от изначальной последовательности
в описании geqo прям написано, что ее результат недетерминирован. Поэтому к результатам ваших тестов доверия не очень много, простите
ну те написание реальное влияет на результат?)))₽!
реально влияет на результат порядок в where? Конечно, нет. Можно ли при использовании geqo получить другой (более быстрый/медленный) план? Конечно. Только при чем работа недетрминированного алгоритма и порядка условий в where?
Оно и в детерминированном влияет
допускаю, что при архисложном запросе планировщик мог не успеть подобрать что-то вменяемое. А потом успеть. Или там у вас были prepared statements, но в целом говорить, что порядок в where влияет на план - смело. Я бы не стал
Конечно в 99 процентов не влияет
Обсуждают сегодня