Re: Built-in connection pooling

On Thu, May 17, 2018 at 9:09 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>> 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.
>
> Yes, I think this matches my previous question --- if we are going to
> swap out session state to allow multiple sessions to multiplex in the
> same OS process, and that swapping has similar overhead to how the OS
> swaps processes, why not just let the OS continue doing the process
> swapping.
>
> I think we need to first find out what it is that makes high session
> counts slow. For example, if we swap out session state, will we check
> the visibility rules for the swapped out session. If not, and that is
> what makes swapping session state make Postgres faster, let's just find
> a way to skip checking visibility rules for inactive sessions and get
> the same benefit more simply.

I don't think we're really in agreement. I am pretty convinced that
we can save a lot of memory and other CPU resources if we don't need a
separate process for each session. I don't have any doubt that the
benefit is there. My point is rather that we need an organized way to
attach the problem of saving and restoring session state, not an
ad-hoc approach for each particular kind of session state.

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