Re: NOT EXIST for PREPARE

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Andreas Karlsson <andreas(at)proxel(dot)se>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Yury Zhuravlev <u(dot)zhuravlev(at)postgrespro(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Tatsuo Ishii <ishii(at)postgresql(dot)org>
Subject: Re: NOT EXIST for PREPARE
Date: 2016-03-24 22:21:14
Message-ID: CAHyXU0waGenNtBMT4KXt2hLzkuWQSvQ392rH390+5byEhbkcBg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Mar 24, 2016 at 2:52 PM, Andreas Karlsson <andreas(at)proxel(dot)se> wrote:
> On 03/23/2016 09:10 PM, Stephen Frost wrote:
>>
>> * Merlin Moncure (mmoncure(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andreas Karlsson 2016-03-24 22:32:42 Re: NOT EXIST for PREPARE
Previous Message Andrew Dunstan 2016-03-24 22:18:00 Re: btree_gin and btree_gist for enums