From: | Ian Barwick <ian(dot)barwick(at)2ndquadrant(dot)com> |
---|---|
To: | Stelios Sfakianakis <sgsfak(at)gmail(dot)com> |
Cc: | Ian Lawrence Barwick <barwick(at)gmail(dot)com>, pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: Keeping state in a foreign data wrapper |
Date: | 2020-08-11 01:19:28 |
Message-ID: | 074df913-4d7b-b392-6870-0bee49003f92@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 2020/08/04 19:21, Stelios Sfakianakis wrote:
> Thank you again, I have another question in order to make sure I have a clear understanding:
>
>
>> On 4 Aug 2020, at 11:24, Ian Lawrence Barwick <barwick(at)gmail(dot)com> wrote:
>>
>> The hash table is specific to each running backend so will only be
>> accessed by that process.
>>
>> Pre-loading a shared library just gives the library an opportunity to
>> set up shared memory etc. You can always try adding one of the FDW
>> libraries to "shared_preload_libraries" and see what happens
>> (theoretically nothing).
>>
>
> My impression was that since each client (e.g. libpq) connection results in the creation of a Postgres process in the backend (https://www.postgresql.org/developer/backend/) then this (mysql) "connection pool" hash table is not global per se and shared among the different client / users sessions.
Correct, the connections are specific to each individual backend.
> But that defeats the purpose, no?
The purpose is to cache connections within the session, to avoid the overhead
of reconnecting to the remote server each time a query for that server is issued
in that session.
Regards
Ian Barwick
--
Ian Barwick https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Flaris Roland Feller | 2020-08-11 02:00:13 | Re: ERROR: invalid memory alloc request size 18446744073709551613 |
Previous Message | Ian Barwick | 2020-08-11 01:19:10 | Re: Keeping state in a foreign data wrapper |