Re: Persistent Plan Cache

Поиск
Список
Период
Сортировка
От Dimitri Fontaine
Тема Re: Persistent Plan Cache
Дата
Msg-id m263bm6kvw.fsf@hi-media.com
обсуждение исходный текст
Ответ на Re: Persistent Plan Cache  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Список 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 по дате отправления:

Предыдущее
От: zz_11@mail.bg
Дата:
Сообщение: Re: possible wrong query plan on pg 8.3.5,
Следующее
От: tv@fuzzy.cz
Дата:
Сообщение: Re: possible wrong query plan on pg 8.3.5,