On Wed, Mar 23, 2016 at 3:10 PM, Stephen Frost <sfr...@snowman.net> wrote: > Merlin, > > * 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. > > Just a thought. I do still like the general idea of INE support for > PREPARE, but perhaps there's a better option.
Admittedly, you make some pretty good points here. I guess one strategy would be to move them all to a function that sets an advisory lock to signal they've been prepared. That's pretty safe even in multi-threaded scenarios since only one thread can send queries to the backend at a time. Advisory locks are pretty arcane though. Still, I'm coming round to your (and Andres's) point of view. :/ merlin merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
