Re: Built-in connection pooling - Mailing list pgsql-hackers

From Tatsuo Ishii
Subject Re: Built-in connection pooling
Date
Msg-id 20180420.075800.2303060526971299155.t-ishii@sraoss.co.jp
Whole thread Raw
In response to Re: Built-in connection pooling  (Andres Freund <andres@anarazel.de>)
Responses Re: Built-in connection pooling  (Michael Paquier <michael@paquier.xyz>)
Re: Built-in connection pooling  (Konstantin Knizhnik <k.knizhnik@postgrespro.ru>)
List pgsql-hackers
> I think there's plenty things that don't really make sense solving
> outside of postgres:
> - additional added hop / context switches due to external pooler

This is only applied to external process type pooler (like Pgpool-II).

> - temporary tables
> - prepared statements
> - GUCs and other session state

These are only applied to "non session based" pooler; sharing a
database connection with multiple client connections. "Session based"
connection pooler like Pgpool-II does not have the shortcomings.

One thing either built-in or application library type pooler (like
JDBC) cannot do is, handle multiple PostgreSQL servers.

> I think there's at least one thing that we should attempt to make
> easier for external pooler:
> - proxy authorization

Yeah. Since SCRAM auth is implemented, some connection poolers
including Pgpool-II are struggling to adopt it.

Another thing PostgreSQL can do to make external pooler's life easier
is, enhancing frontend/backend protocol so that reply messages of
prepare etc. include portal/statement info. But apparently this needs
protocol changes.

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Double-writes, take two?
Next
From: Michael Paquier
Date:
Subject: Re: Double-writes, take two?