Re: Built-in connection pooling

On Mon, Apr 23, 2018 at 09:53:37PM -0400, Bruce Momjian wrote:
> On Mon, Apr 23, 2018 at 09:47:07PM -0400, Robert Haas wrote:
> > On Mon, Apr 23, 2018 at 7:59 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> > > So, instead of trying to multiplex multiple sessions in a single
> > > operating system process, why don't we try to reduce the overhead of
> > > idle sessions that each have an operating system process? We already
> > > use procArray to reduce the number of _assigned_ PGPROC entries we have
> > > to scan. Why can't we create another array that only contains _active_
> > > sessions, i.e. those not in a transaction. In what places can procArray
> > > scans be changed to use this new array?
> >
> > There are lots of places where scans would benefit, but the cost of
> > maintaining the new array would be very high in some workloads, so I
> > don't think you'd come out ahead overall. Feel free to code it up and
> > test it, though.
>
> Well, it would be nice if we new exactly which scans are slow for a
> large number of idle sessions, and then we could determine what criteria
> for that array would be beneficial --- that seems like the easiest place
> to start.

I guess my point is if we are looking at trying to store all the session
state in shared memory, so any process can resume it, we might as well
see if we can find a way to more cheaply store the state in an idle
process.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +