![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Очередной срачъ, у zabivator-а
Я всегда думал, что может заставить людей не использовать связываемые параметры в запросах и извращаться с самостоятельной конкатенацией запросов, проверкой на sql-инъекции, эскейпингом, обработкой локалей и форматов и прочим садомазохизмом при работе с СУБД.
Оказывается, bind-параметры влияют на производительность.
То, что он формально прав, и что, зная значения параметров, СУБД может выбрать более оптимальный план, не меняет того факта, что это сродни ассемблерным вставкам и экономии на количестве переменных на стеке при разработке опердени, чтобы "работало быстрее".
Я счас поискал в гугле про подобные проблемы - у людей с OSM подобная фигня с бинд-параметрами в Postgresql вылезла. Но это на таблице в 500 млн записей и очень хитрожопном запросе. Предполагаю, что с такими объемами на обычной опердени жопа начнется намного раньше, чем разница между планами хоть как-то повлияет.
Не говоря уже о том, что правильный план можно прибить гвоздями, как минимум в Firebird так точно и вообще не мучится.
Оказывается, bind-параметры влияют на производительность.
То, что он формально прав, и что, зная значения параметров, СУБД может выбрать более оптимальный план, не меняет того факта, что это сродни ассемблерным вставкам и экономии на количестве переменных на стеке при разработке опердени, чтобы "работало быстрее".
Я счас поискал в гугле про подобные проблемы - у людей с OSM подобная фигня с бинд-параметрами в Postgresql вылезла. Но это на таблице в 500 млн записей и очень хитрожопном запросе. Предполагаю, что с такими объемами на обычной опердени жопа начнется намного раньше, чем разница между планами хоть как-то повлияет.
Не говоря уже о том, что правильный план можно прибить гвоздями, как минимум в Firebird так точно и вообще не мучится.
no subject
no subject
no subject
Решается bind-параметрами.
no subject
no subject