From: | Greg Stark <stark(at)mit(dot)edu> |
---|---|
To: | Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Separate connection handling from backends |
Date: | 2016-12-07 01:58:19 |
Message-ID: | CAM-w4HOX5nSEF-3GMEGdCgXCpysLK=BuEHM39VZA7FK28Gnq1A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 5 December 2016 at 19:48, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-12-07 02:07:09 | Re: [GENERAL] Select works only when connected from login postgres |
Previous Message | legrand legrand | 2016-12-06 23:29:53 | Partitionning: support for Truncate Table WHERE |