On 03/23/2016 09:10 PM, Stephen Frost wrote:
> * Merlin Moncure (mmoncure@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