[pgpool-general: 9256] Re: Question about the global pool

Achilleas Mantzios - cloud a.mantzios at cloud.gatewaynet.com
Thu Oct 31 15:49:34 JST 2024


On 10/31/24 07:21, Tatsuo Ishii wrote:

>>>> So that we
>>>> can finally have the one and only pooler that we need which does it
>>>> all? (load balancing, pooling, read-write split, etc)
>>> Just out of curiosity, those features (load balancing, pooling,
>>> read-write split) are already available in existing Pgpool-II
>>> versions. What feature do you think lacking in current Pgpool-II
>>> versions?
>> I meant more efficient pooling (like pgbouncer), transaction-level
>> pooling. Speaking of which pgbouncer also now supports prepared
>> statements , any plans for prepared statements in Pgpool-II ?
> For more efficient pooling, Usama's work should be useful and will be
> in Pgpool-II 4.6.  Unfortunately the transaction-level connection
> pooling will not be available in 4.6. According to Usama, he needs
> more time to make it mature.
Good news, thank you!
> In my understanding prepared statements are already supported in
> Pgpool-II 4.5.
>> Allow to load balance PREPARE/EXECUTE/DEALLOCATE.
> https://www.pgpool.net/docs/latest/en/html/release-4-5-0.html
>
> Or do you mean something else?

I mean the prepared statements via the protocol level, not via 
PREPARE/EXECUTE. I don't know the specifics about upcoming 4.6, but I'll 
describe what happens now in PgBouncer 1.23.1 
<https://www.pgbouncer.org/2024/08/pgbouncer-1-23-1> . : 
https://www.pgbouncer.org/config.html#max_prepared_statements

It is a mechanism to cope with prepared statements in transaction and 
statement pooling mode, which in Pgpool-II still is not implemented. 
Statement-pooling mode, IMHO is irrelevant to the classical/common 
PostgreSQL use case, but the transaction-level pooling mode is very 
useful. And in order to support transaction-pooling with prepared 
statements, the pooler must keep track of all prepared statements coming 
from all clients, identify unique queries, encode them in a internal 
manner, and then take care that each client that has requested a 
prepared statement has this statement ready in the server, even if this 
a newly created server with no knowledge of the prepared statement. We 
haven't tested it yet, though.

>
> Best reagards,
> --
> Tatsuo Ishii
> SRA OSS K.K.
> English:http://www.sraoss.co.jp/index_en/
> Japanese:http://www.sraoss.co.jp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pgpool.net/pipermail/pgpool-general/attachments/20241031/c42c2efb/attachment.htm>


More information about the pgpool-general mailing list