On 03/23/2016 09:10 PM, Stephen Frost wrote:
* Merlin Moncure (mmonc...@gmail.com) wrote:
No one is arguing that that you should send it any every time (at
least -- I hope not).
I'm not sure I follow how you can avoid that though?
pgbouncer in transaction pooling mode may let a particular connection
die off and then, when you issue a new request, create a new one- which
won't have any prepared queries in it, even though you never lost your
connection to pgbouncer.
That's why I was saying you'd have to send it at the start of every
transaction, which does add to network load and requires parsing, etc.
Would be nice to avoid that, if possible, but I'm not quite sure how.
One thought might be to have the server somehow have a pre-canned set of
queries already set up and ready for you to use when you connect,
without any need to explicitly prepare them, etc.
Personally I think the right solution would be to add support for
prepared statements in pgbouncer, and have pgbouncer run PREPARE as
necessary, either after opening a new connection to the database or at
the first use of a given prepared statement in a connection.
Application level connection poolers with prepared statement support,
e.g. sequel for Ruby, does not need any special support from PostgreSQL
and work just fine with our current feature set.
Andreas
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
