Re: Avoiding bad prepared-statement plans.

On Thu, Feb 25, 2010 at 20:40, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> It's not going to be easier to implement.  Yeah, it would be easy to
> provide a global switch via a GUC setting, but that's not going to be
> helpful, because this is the sort of thing that really needs to be
> managed per-query.  Almost any nontrivial application is going to have
> some queries that really need the custom plan and many that don't.
> If people just turn the GUC on we might as well throw away the plan
> caching mechanism altogether.  But putting support for a per-query level
> of control into the protocol (and then every client library) as well as
> every PL is going to be painful to implement, and even more painful to
> use.

Not to mention you can already do this more or less client side with a
nice driver.  For example with DBD::Pg i can say:

$sth = $dbh->prepare('select * from foo where x = ?', {'pg_server_prepare'=>1});

To get a prepared plan (it is also the default).

If for a particular query I know that I will get a better plan without
prepare, I can just change that 1 to a 0.  Or I can set it globally
via $dbh->{'pg_server_prepare'} = 0;

In other words im not quite sure what this would buy us.