From: | bricklen <bricklen(at)gmail(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Poor plan choice in prepared statement |
Date: | 2008-12-30 23:11:47 |
Message-ID: | 33b743250812301511x30f1b377uf55fdca82d243c37@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Hi Tom,
On Tue, Dec 30, 2008 at 3:02 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | david | 2008-12-31 00:19:01 | Re: Poor plan choice in prepared statement |
Previous Message | Tom Lane | 2008-12-30 23:02:29 | Re: Poor plan choice in prepared statement |