Tom Lane escribió: > Scott Carey <scott@xxxxxxxxxxxxxxxxx> 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. I think it has been shown enough times that the performance drop caused by a worse plan can be orders of magnitudes worse than what's gained by producing the plan only once. It does not seem a bad idea to provide a way to carry out only the parse phase, and postpone planning until the parameters have been received. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
