On Fri, May 4, 2018 at 5:54 PM, Merlin Moncure <mmonc...@gmail.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
