From: | Dimitri Fontaine <dfontaine(at)hi-media(dot)com> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | Joshua Rubin <jrubin(at)esoft(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Persistent Plan Cache |
Date: | 2009-09-14 07:33:23 |
Message-ID: | m263bm6kvw.fsf@hi-media.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Hi,
Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
> Joshua Rubin wrote:
>> We "hardcode" the parts of the where clause so that the prepared plan
>> will not vary among the possible partitions of the table. The only
>> values that are bound would not affect the planner's choice of table.
>
> Then you would benefit from using prepared statements in the client,
> and/or connection pooling to avoid having to re-prepare because of
> reconnecting.
And you can do both in a transparent way (wrt pooling) using
preprepare. The problem without it is for the application to know when
the statement is already prepared (that depends on whether the pooling
software will assign a new fresh connection or not). Using preprepare
your application skip the point and simply EXECUTE the already prepared
statements.
http://preprepare.projects.postgresql.org/README.html
http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/preprepare/preprepare/
http://packages.debian.org/search?keywords=preprepare
Regards,
--
dim
From | Date | Subject | |
---|---|---|---|
Next Message | tv | 2009-09-14 09:32:45 | Re: possible wrong query plan on pg 8.3.5, |
Previous Message | zz_11 | 2009-09-14 06:16:32 | Re: possible wrong query plan on pg 8.3.5, |