| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
| Cc: | Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>, Christophe Pettus <xof(at)thebuild(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Nikolay Samokhvalov <samokhvalov(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Built-in connection pooling |
| Date: | 2018-05-04 19:25:15 |
| Message-ID: | CA+TgmoboprWQLvAoOagnE82Dy9jFbOjgeP_YybtL_+S7ZO2Hgg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, May 4, 2018 at 11:22 AM, Merlin Moncure <mmoncure(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jonathan S. Katz | 2018-05-04 19:38:24 | PostgreSQL 11 Beta 1 Release: 2018-05-24 |
| Previous Message | Mark Dilger | 2018-05-04 19:24:27 | genbki.pl not quoting keywords in postgres.bki output |