Re: Poor plan choice in prepared statement
От | bricklen |
---|---|
Тема | Re: Poor plan choice in prepared statement |
Дата | |
Msg-id | 33b743250812301511x30f1b377uf55fdca82d243c37@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Poor plan choice in prepared statement (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-performance |
Hi Tom, On Tue, Dec 30, 2008 at 3:02 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > 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 agree, and normally it wouldn't be an issue. In this particular case, we are seeing response time to go from sub-second with non-prepared queries, to over 200 seconds w/ prepared queries. Note that is not an isolated case in our application, merely the numbers from this particular example. > > 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 > Again, I agree completely. What I am after I guess are some pointers on where to look for that, with regards to PHP. Whatever I turn up, I will turn over to our developers, but before I do that I want to be sure I am giving them the correct advice. Thanks, Bricklen
В списке pgsql-performance по дате отправления: