Subject: Re: Built-in connection pooler
To: Michael Paquier <michael@paquier.xyz>,
 Dimitri Fontaine <dimitri@citusdata.com>
Cc: Bruce Momjian <bruce@momjian.us>,
 PostgreSQL Hackers <pgsql-hackers@postgresql.org>
References: <ac873432-31cf-d5e4-0b80-b5ac95cfe385@postgrespro.ru>
 <20190128211040.GF26761@momjian.us> <m2a7jk8o31.fsf@laptop.tapoueh.org>
 <20190129051403.GF3121@paquier.xyz>
From: Konstantin Knizhnik <k.knizhnik@postgrespro.ru>
Message-ID: <8ebc2478-260f-d937-e607-eef4429790de@postgrespro.ru>
Date: Tue, 29 Jan 2019 12:21:33 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <20190129051403.GF3121@paquier.xyz>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Precedence: bulk


On 29.01.2019 8:14, Michael Paquier wrote:
> On Mon, Jan 28, 2019 at 10:33:06PM +0100, Dimitri Fontaine wrote:
>> In other cases, it's important to measure and accept the possible
>> performance cost of running a proxy server between the client connection
>> and the PostgreSQL backend process. I believe the numbers shown in the
>> previous email by Konstantin are about showing the kind of impact you
>> can see when using the patch in a use-case where it's not meant to be
>> helping much, if at all.
> Have you looked at the possibility of having the proxy worker be
> spawned as a background worker?

Yes, it was my first attempt.
The main reason why I have implemented it in old ways are:
1. I need to know PID of spawned worker. Strange - it is possible to get 
PID of dynamic bgworker, but no of static one.
Certainly it is possible  to find a way of passing this PID to 
postmaster but it complicates start of worker.
2. I need to pass socket to spawner proxy.  Once again: it can be 
implemented also with bgworker but requires more coding (especially 
taken in account support of Win32 and FORKEXEC mode).

>   I think that we should avoid spawning
> any new processes on the backend from the ground as we have a lot more
> infrastructures since 9.3.  The patch should actually be bigger, the
> code is very raw and lacks comments in a lot of areas where the logic
> is not so obvious, except perhaps to the patch author.

The main reason for publishing this patch was to receive feedbacks and 
find places which should be rewritten.
I will add more comments but I will be pleased if you point me which 
places are obscure now and require better explanation.


-- 
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company