Re: Avoiding bad prepared-statement plans. - Mailing list pgsql-hackers

From Alex Hunsaker
Subject Re: Avoiding bad prepared-statement plans.
Date
Msg-id 34d269d41002252028n196327a0kc2ad47add6bab422@mail.gmail.com
Whole thread Raw
In response to Re: Avoiding bad prepared-statement plans.  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Avoiding bad prepared-statement plans.  (Alex Hunsaker <badalex@gmail.com>)
List pgsql-hackers
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.


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Avoiding bad prepared-statement plans.
Next
From: Gokulakannan Somasundaram
Date:
Subject: Re: A thought on Index Organized Tables