On 2018-04-19 15:01:24 -0400, Tom Lane wrote:
> Only after you can say "there's nothing wrong with this that isn't
> directly connected to its not being in-core" does it make sense to try
> to push the logic into core.
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
- temporary tables
- prepared statements
- GUCs and other session state
Totally agreed. Poolers can make some limited efforts there, but that's all.
Poolers also have a hard time determining if a query is read-only or read/write. Wheas Pg its self has a better chance, and we could help it along with function READONLY attributes if we wanted. This matters master/standby query routing. Standbys being able to proxy for the master would be fantastic but isn't practical without some kind of pooler.
I think there's at least one thing that we should attempt to make
easier for external pooler:
- proxy authorization
Yes, very yes. I've raised this before in a limited form - SET SESSION AURHORIZATION that cannot be reset without a cookie value. But true proxy auth would be better.