| From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
|---|---|
| To: | Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>, Nikolay Samokhvalov <samokhvalov(at)gmail(dot)com> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Built-in connection pooling |
| Date: | 2018-04-18 13:41:19 |
| Message-ID: | ee7a5662-48d6-3de7-8bf0-48757da836e0@iki.fi |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 18/04/18 07:52, Konstantin Knizhnik wrote:
>
>
> On 18.04.2018 13:36, Heikki Linnakangas wrote:
>> On 18/04/18 06:10, Konstantin Knizhnik wrote:
>>> But there are still use cases which can not be covered y external
>>> connection pooler.
>>
>> Can you name some? I understand that the existing external connection
>> poolers all have their limitations. But are there some fundamental
>> issues that can *only* be addressed by a built-in implementation?
>
> Well, may be I missed something, but i do not know how to efficiently
> support
> 1. Temporary tables
> 2. Prepared statements
> 3. Sessoin GUCs
> with any external connection pooler (with pooling level other than session).
Me neither. What makes it easier to do these things in an internal
connection pooler? What could the backend do differently, to make these
easier to implement in an external pooler?
- Heikki
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Konstantin Knizhnik | 2018-04-18 13:46:23 | Re: Built-in connection pooling |
| Previous Message | Alvaro Herrera | 2018-04-18 13:40:07 | Re: ON CONFLICT DO UPDATE for partitioned tables |