Re: Persistent Plan Cache - Mailing list pgsql-performance

From Dimitri Fontaine
Subject Re: Persistent Plan Cache
Date
Msg-id m263bm6kvw.fsf@hi-media.com
Whole thread Raw
In response to Re: Persistent Plan Cache  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List pgsql-performance
Hi,

Heikki Linnakangas <heikki.linnakangas@enterprisedb.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

pgsql-performance by date:

Previous
From: zz_11@mail.bg
Date:
Subject: Re: possible wrong query plan on pg 8.3.5,
Next
From: tv@fuzzy.cz
Date:
Subject: Re: possible wrong query plan on pg 8.3.5,