Re: Persistent Plan Cache

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

In response to

Browse pgsql-performance by date

  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,