Re: Built-in connection pooling

On 01/19/2018 06:13 PM, Claudio Freire wrote:
> 
> 
> On Fri, Jan 19, 2018 at 2:07 PM, Konstantin Knizhnik
> <k.knizhnik@postgrespro.ru <mailto:k.knizhnik@postgrespro.ru>> wrote:
> 
> 
> 
> 
>         Well, I haven't said it has to be single-threaded like pgbouncer. I
>         don't see why the bgworker could not use multiple threads
>         internally (of
>         course, it'd need to be not to mess the stuff that is not
>         thread-safe).
> 
> 
>     Certainly architecture with N multiple scheduling bgworkers and M
>     executors (backends) may be more flexible
>     than solution when scheduling is done in executor itself. But we
>     will have to pay extra cost for redirection.
>     I am not sure that finally it will allow to reach better performance.
>     More flexible solution in many cases doesn't mean more efficient
>     solution.
> 
> 
> I think you can take the best of both worlds.
> 
> You can take your approach of passing around fds, and build a "load
> balancing protocol" in a bgworker.
> 
> The postmaster sends the socket to the bgworker, the bgworker waits for
> a command as pgbouncer does, but instead of proxying everything, when
> commands arrive, it passes the socket to a backend to handle.
> 
> That way, the bgworker can do what pgbouncer does, handle different
> pooling modes, match backends to databases, etc, but it doesn't have to
> proxy all data, it just delegates handling of a command to a backend,
> and forgets about that socket.
> 
> Sounds like it could work.
> 

How could it do all that without actually processing all the data? For
example, how could it determine the statement/transaction boundaries?


-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services