Re: NOT EXIST for PREPARE
От | Merlin Moncure |
---|---|
Тема | Re: NOT EXIST for PREPARE |
Дата | |
Msg-id | CAHyXU0waGenNtBMT4KXt2hLzkuWQSvQ392rH390+5byEhbkcBg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: NOT EXIST for PREPARE (Andreas Karlsson <andreas@proxel.se>) |
Ответы |
Re: NOT EXIST for PREPARE
|
Список | pgsql-hackers |
On Thu, Mar 24, 2016 at 2:52 PM, Andreas Karlsson <andreas@proxel.se> wrote: > 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. 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
В списке pgsql-hackers по дате отправления: