From: | Cédric Villemain <cedric(at)2ndquadrant(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Cc: | Merlin Moncure <mmoncure(at)gmail(dot)com>, Samba <saasira(at)gmail(dot)com>, Martijn van Oosterhout <kleptog(at)svana(dot)org> |
Subject: | Re: Global Named Prepared Statements |
Date: | 2012-05-21 15:12:08 |
Message-ID: | 201205211712.08608.cedric@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Steve Crawford | 2012-05-21 16:08:01 | Re: odd intermittent query hanging issue |
Previous Message | Cédric Villemain | 2012-05-21 15:09:53 | Re: help understanding the bitmap heap scan costs |