Re: Separate connection handling from backends - Mailing list pgsql-hackers

From Greg Stark
Subject Re: Separate connection handling from backends
Date
Msg-id CAM-w4HOX5nSEF-3GMEGdCgXCpysLK=BuEHM39VZA7FK28Gnq1A@mail.gmail.com
Whole thread Raw
In response to Separate connection handling from backends  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Responses Re: Separate connection handling from backends  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 5 December 2016 at 19:48, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
> One solution to this would be to segregate connection handling from actual
> backends, somewhere along the lines of separating the main loop from the
> switch() that handles libpq commands. Benefits:

I'm kind of mystified how a simple code restructuring could solve the
fundamental problems with a large number of backends. It sounds like
what you're describing would just push the problem around, you would
end up with some other maximum instead, max_backends, or
max_active_backends, or something like that with the same problems.
At best it would help people who have connection pooling or but few
connections active at any given time.

Heikki's work with CSN would actually address the main fundamental
problem. Instead of having to scan PGPROC when taking a snapshot
taking a snapshot would be O(1). There might need to be scans of the
list of active transactions but never of all connections whether
they're in a transaction or not.

-- 
greg



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: WIP: Faster Expression Processing and Tuple Deforming (including JIT)
Next
From: Tom Lane
Date:
Subject: Re: [GENERAL] Select works only when connected from login postgres