Re: Built-in connection pooler - Mailing list pgsql-hackers

From Konstantin Knizhnik
Subject Re: Built-in connection pooler
Date
Msg-id 0d9c9165-3389-dd70-3429-df2facce44ec@garret.ru
Whole thread Raw
In response to Re: Built-in connection pooler  (Zhihong Yu <zyu@yugabyte.com>)
List pgsql-hackers
Hi,
Thank you for review!

On 21.03.2021 23:59, Zhihong Yu wrote:
> Hi,
>
> +          With <literal>load-balancing</literal> policy postmaster 
> choose proxy with lowest load average.
> +          Load average of proxy is estimated by number of clients 
> connection assigned to this proxy with extra weight for SSL connections.
>
> I think 'load-balanced' may be better than 'load-balancing'.

Sorry, I am not a native speaker.
But it seems to me (based on the articles I have read), then 
"load-balancing" is more widely used term:

https://en.wikipedia.org/wiki/Load_balancing_(computing)

> postmaster choose proxy -> postmaster chooses proxy

Fixed.

>
> +          Load average of proxy is estimated by number of clients 
> connection assigned to this proxy with extra weight for SSL connections.
>
> I wonder if there would be a mixture of connections with and without SSL.
Why not? And what is wrong with it?

>
> +         Terminate an idle connection pool worker after the specified 
> number of milliseconds.
>
> Should the time unit be seconds ? It seems a worker would exist for at 
> least a second.
>
Most of other similar timeouts: statement timeout, session timeout... 
are specified in milliseconds.

> + * Portions Copyright (c) 1996-2018, PostgreSQL Global Development Group
>
> It would be better to update the year in the header.

Fixed.

>
> +        * Use then for launching pooler worker backends and report error
>
> Not sure I understand the above sentence. Did you mean 'them' instead 
> of 'then' ?

Sorry, it is really mistyping.
"them" should be used.
Fixed.




pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: [PATCH] Identify LWLocks in tracepoints
Next
From: Andrei Zubkov
Date:
Subject: Re: [PATCH] pg_stat_statements dealloc field ignores manual deallocation