On Tue, May 25, 2010 at 11:27:08AM -0700, Scott Carey wrote:
> On May 21, 2010, at 8:26 PM, Matthew Wakeling wrote:
> > On Fri, 21 May 2010, Richard Yen wrote:
> >> Any ideas why the query planner chooses a different query plan when using
> >> prepared statements?
> >
> > This is a FAQ. Preparing
On May 21, 2010, at 8:26 PM, Matthew Wakeling wrote:
> On Fri, 21 May 2010, Richard Yen wrote:
>> Any ideas why the query planner chooses a different query plan when using
>> prepared statements?
>
> This is a FAQ. Preparing a statement makes Postgres create a plan, without
> knowing the value
On Fri, 21 May 2010, Richard Yen wrote:
Any ideas why the query planner chooses a different query plan when using
prepared statements?
This is a FAQ. Preparing a statement makes Postgres create a plan, without
knowing the values that you will plug in, so it will not be as optimal as
if the v
On Fri, May 21, 2010 at 4:53 PM, Richard Yen wrote:
> Any ideas why the query planner chooses a different query plan when using
> prepared statements?
A prepared plan is the best one the planner can come up with *in
general* for the query in question. If the distribution of the values
you're qu
Hi everyone,
I use DBD::Pg to interface with our 8.4.2 database, but for a particular query,
performance is horrible. I'm assuming that the behavior of $dbh->prepare is as
if I did PREPARE foo AS (query), so I did an explain analyze in the commandline:
> db_alpha=# prepare foo6 as (SELECT me.id
