Scott Carey <sc...@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
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
