Re: Global Named Prepared Statements

Поиск
Список
Период
Сортировка
От Cédric Villemain
Тема Re: Global Named Prepared Statements
Дата
Msg-id 201205211712.08608.cedric@2ndquadrant.com
обсуждение исходный текст
Ответ на Re: Global Named Prepared Statements  (Merlin Moncure <mmoncure@gmail.com>)
Список pgsql-general
Le lundi 21 mai 2012 16:08:27, Merlin Moncure a écrit :
> On Mon, May 21, 2012 at 8:55 AM, Samba <saasira@gmail.com> wrote:
> > If Stored Procedures are equivalent to prepared statements [ as far as
> > preparing the query plan is concerned], then what i'm looking for is
> > perhaps a Global Prepared Statements at the client/driver side.
> >
> > Specifically, It wold be good if the JDBC driver prepares all the queries
> > for invoking stored procedures at once per JVM so that each connection
> > need not incur the cost of preparing [parsing and storing] those queries
> > per connection.
> >
> > Thus we can put all the queries [stored procedure calls] at a single
> > place, and prepare those queries during boot of the server [or
> > deployment of the web application], and then execute those queries
> > endless times by closing just the resultset object while keeping the
> > statement open for ever.
> >
> > I know this is not form to discuss the JDBC related questions but put my
> > thoughts here to complete the question i raised. If folks think this idea
> > is valid then i will take it up with the JDBC Driver team.
>
> Well, there is a client side component to statement preparation which
> the JDBC driver also does.
>
> There is a reason why there are no global plans in postgres: it
> complicates everything in the sense that there you have to deal with
> shared memory, locking. and scope/lifetime issues.  Even though it can
> be a big reduction in memory consumption you're on the wrong side of
> the tradeoff for most cases.  If you want to leverage server side
> objects with >1 client connections I strongly advise looking at a
> connection pooler -- not the lame client side pooling solutions you
> typically see with the java stack -- but something like pgbouncer.
> This amortizes memory costs of server side plans.   pgbouncer is
> mostly compatible with JDBC; you have to disable automatic statement
> preparation.

and there is preprepare to help with prepared_statement and pgbouncer:

https://github.com/dimitri/preprepare


--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation

Вложения

В списке pgsql-general по дате отправления:

Предыдущее
От: Cédric Villemain
Дата:
Сообщение: Re: help understanding the bitmap heap scan costs
Следующее
От: Steve Crawford
Дата:
Сообщение: Re: odd intermittent query hanging issue