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 functions. melrin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
