Re: Built-in connection pooling

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: Built-in connection pooling
Дата
Msg-id 20180423235934.GB12787@momjian.us
обсуждение исходный текст
Ответ на Re: Built-in connection pooling  (Konstantin Knizhnik <k.knizhnik@postgrespro.ru>)
Ответы Re: Built-in connection pooling  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Fri, Apr 20, 2018 at 11:40:59AM +0300, Konstantin Knizhnik wrote:
> 
> Sorry, may we do not understand each other.
> There are the following facts:
> 1. There are some entities in Postgres which are local to a backend:
> temporary tables, GUCs, prepared statement, relation and catalog caches,...
> 2. Postgres doesn't "like"  larger number of backends. Even only few of them
> are actually active. Large number of backends means large procarray, large
> snapshots,...
> Please refere to my measurement at the beginning of this thread which
> illustrate how performance of Pastgres degrades with increasing number of
> backends.

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?

-- 
  Bruce Momjian  <bruce@momjian.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 +


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: perltidy version
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS