Re: Named Prepared statement problems and possible solutions - Mailing list pgsql-hackers

From Dave Cramer
Subject Re: Named Prepared statement problems and possible solutions
Date
Msg-id CADK3HHKoroMwVneDFmU6hvvMmOkAH-YTVGhmMU9iJCJu=CEM4g@mail.gmail.com
Whole thread Raw
In response to Re: Named Prepared statement problems and possible solutions  (Jan Wieck <jan@wi3ck.info>)
List pgsql-hackers


On Thu, 8 Jun 2023 at 09:53, Jan Wieck <jan@wi3ck.info> wrote:
On 6/8/23 09:21, Dave Cramer wrote:
>
>
> On Thu, Jun 8, 2023 at 8:43 AM Jan Wieck <jan@wi3ck.info
> <mailto:jan@wi3ck.info>> wrote:
>
>     On 6/8/23 02:15, Konstantin Knizhnik wrote:
>
>      > There is a PR with support of prepared statement support to
>     pgbouncer:
>      > https://github.com/pgbouncer/pgbouncer/pull/845
>     <https://github.com/pgbouncer/pgbouncer/pull/845>
>      > any feedback, reviews and suggestions are welcome.
>
>     I was about to say that the support would have to come from the pooler
>     as it is possible to have multiple applications in different languages
>     connecting to the same pool(s).
>
>
> Why from the pooler? If it were done at the server every client could
> use it?

The server doesn't know about all the clients of the pooler, does it? It
has no way of telling if/when a client disconnects from the pooler.

Why does it have to know if the client disconnects ? It just keeps a cache of prepared statements. 
In large apps it is very likely there will be another client wanting to use the statement

Dave 

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Error in calculating length of encoded base64 string
Next
From: Dave Cramer
Date:
Subject: Re: Named Prepared statement problems and possible solutions