On Thu, Mar 24, 2016 at 2:52 PM, Andreas Karlsson <andr...@proxel.se> wrote:
> 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.

maybe so. A while back I was running a hacked pgbouncer that had
support for async notifications (i still have the code around
somewhere).  It can be done -- however this not a complete solution;
both LISTEN and PREPARE are possible from within server-side


Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to