Re: Separate connection handling from backends

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: Separate connection handling from backends
Дата
Msg-id CAM-w4HOX5nSEF-3GMEGdCgXCpysLK=BuEHM39VZA7FK28Gnq1A@mail.gmail.com
обсуждение исходный текст
Ответ на Separate connection handling from backends  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Ответы Re: Separate connection handling from backends  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: WIP: Faster Expression Processing and Tuple Deforming (including JIT)
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [GENERAL] Select works only when connected from login postgres