On Tue, 30 Dec 2008, Tom Lane wrote:
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.
actually, it does two things
1. planning only once
2. parsing only once.
I suspect that when this was initially setup the expectation was that the
planning was the expensive thing that should be avoided.
in this case a post earlier in the thread identified parsing of the query
as being the expensive thing (planning + execution was 1/3 the cost of the
parsing)
since there is not a pre-parsed interface for queries, it may make sense
to setup a way to have the query pre-parsed, but not pre-planned for cases
like this.
David Lang
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
