Re: Built-in connection pooling - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Built-in connection pooling
Date
Msg-id CA+TgmoboprWQLvAoOagnE82Dy9jFbOjgeP_YybtL_+S7ZO2Hgg@mail.gmail.com
Whole thread Raw
In response to Re: Built-in connection pooling  (Merlin Moncure <mmoncure@gmail.com>)
Responses Re: Built-in connection pooling  (Merlin Moncure <mmoncure@gmail.com>)
Re: Built-in connection pooling  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On Fri, May 4, 2018 at 11:22 AM, Merlin Moncure <mmoncure@gmail.com> wrote:
> If we are breaking 1:1 backend:session relationship, what controls
> would we have to manage resource consumption?

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.

However, I think that's probably worrying about the wrong end of the
problem first.  IMHO, what we ought to start by doing is considering
what a good architecture for this would be, and how to solve the
general problem of per-backend session state.  If we figure that out,
then we could worry about optimizing whatever needs optimizing, e.g.
memory usage.

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


pgsql-hackers by date:

Previous
From: Mark Dilger
Date:
Subject: genbki.pl not quoting keywords in postgres.bki output
Next
From: "Jonathan S. Katz"
Date:
Subject: PostgreSQL 11 Beta 1 Release: 2018-05-24