Re: Separate connection handling from backends

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

In response to

Responses

Browse pgsql-hackers by date

  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