Re: Built-in connection pooling

On Fri, May 4, 2018 at 5:54 PM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
>> I mean, if you have a large number of sessions open, it's going to
>> take more memory in any design. If there are multiple sessions per
>> backend, there may be some possibility to save memory by allocating it
>> per-backend rather than per-session; it shouldn't be any worse than if
>> you didn't have pooling in the first place.
>
> It is absolutely worse, or at least can be. plpgsql plan caches can
> be GUC dependent due to search_path; you might get a different plan
> depending on which tables resolve into the function. You might
> rightfully regard this as an edge case but there are other 'leakages',
> for example, sessions with different planner settings obviously ought
> not to share backend plans. Point being, there are many
> interdependent things in the session that will make it difficult to
> share some portions but not others.

I think you may be misunderstanding my remarks. Suppose I've got 10
real connections multiplexed across 1000 sessions. Barring a
crazy-stupid implementation, that should never use more memory than
1000 completely separate connections. (How could it?) It will of
course use a lot more memory than 10 real connections handling 10
sessions, but that's to be expected.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company