Hi, Heikki Linnakangas <heikki.linnakangas@xxxxxxxxxxxxxxxx> 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 -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
