From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Dimitri Fontaine <dimitri(at)citusdata(dot)com> |
Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Built-in connection pooler |
Date: | 2019-01-29 05:14:03 |
Message-ID: | 20190129051403.GF3121@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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? 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.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2019-01-29 05:19:09 | Re: pg_basebackup, walreceiver and wal_sender_timeout |
Previous Message | Michael Paquier | 2019-01-29 05:08:30 | Re: pg_upgrade: Pass -j down to vacuumdb |