Re: Poor plan choice in prepared statement

From: "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com>
To: "Merlin Moncure" <mmoncure(at)gmail(dot)com>
Cc: bricklen <bricklen(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Poor plan choice in prepared statement
Date: 2008-12-30 20:09:55
Message-ID: dcc563d10812301209i59bf612eidc42fa408d4441ab@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Tue, Dec 30, 2008 at 12:42 PM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
> On Tue, Dec 30, 2008 at 1:59 PM, bricklen <bricklen(at)gmail(dot)com> wrote:
>> Hi, I am re-posting my question here after trying to find a solution
>> in the PHP pgsql list with no luck.
>>
>> I am experiencing some performance issues that I think are stemming
>> from prepared statements. I have a pretty simple query:
>> -- bad plan, from prepared statement
>> --
>> dev=# prepare fooplan (date,date,int,int) as
>> dev-# SELECT cl.idOffer AS campaign, cl.idAffiliate AS affiliate,
>> cl.idCreative AS creative, cl.subid, cl.datetime
>> dev-# FROM click AS cl LEFT JOIN conversion AS co ON cl.clickGenerated
>> = co.clickGenerated
>> dev-# WHERE cl."date" >= $1
>> dev-# AND cl."date" <= $2
>> dev-# AND cl.idAffiliate = $3
>> dev-# LIMIT $4;
>
> Your problem is that the query as written is hard to plan. The
> database has no idea what you pass in, it has to guess. (IMO, It
> almost always guesses wrong...I think it should assume 1 row
> returned). Also, the db has no idea what you want to pass in at plan
> time for date.

One of the things you can try here is to build your query then execute
it so it has to be planned each time.

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message bricklen 2008-12-30 20:14:34 Re: Poor plan choice in prepared statement
Previous Message bricklen 2008-12-30 19:55:15 Re: Poor plan choice in prepared statement