Re: Poor plan choice in prepared statement

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Poor plan choice in prepared statement
Дата
Msg-id 2796.1230678149@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Poor plan choice in prepared statement  (Scott Carey <scott@richrelevance.com>)
Ответы Re: Poor plan choice in prepared statement  (bricklen <bricklen@gmail.com>)
Re: Poor plan choice in prepared statement  (david@lang.hm)
Re: Poor plan choice in prepared statement  (Alvaro Herrera <alvherre@commandprompt.com>)
Список pgsql-performance
Scott Carey <scott@richrelevance.com> writes:
> I have also had a case where one query would take a  couple hundred ms to parse, but was fairly fast to plan and
execute(1/3 the parse cost) -- yet another case where a prepared statement that re-plans each execution would be
helpful. At least you can prevent SQL injection and cut the parse cost.  Its not all about the cost of planning the
query.

The point of a prepared statement IMHO is to do the planning only once.
There's necessarily a tradeoff between that and having a plan that's
perfectly adapted to specific parameter values.

Reasonable client-side APIs should provide the option to use out-of-line
parameters, which is what you want to prevent SQL injection, without
hard-wiring that to the orthogonal concept of statements whose plan is
prepared in advance.  In libpq, for instance, PQexecParams() does that.

            regards, tom lane

В списке pgsql-performance по дате отправления:

Предыдущее
От: bricklen
Дата:
Сообщение: Re: Poor plan choice in prepared statement
Следующее
От: bricklen
Дата:
Сообщение: Re: Poor plan choice in prepared statement