Re: Built-in connection pooling

> 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