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?
It only needs to determine statement/transaction start.
After that, it hands off the connection to a backend, and the backend determines when to give it back.
So instead of processing all the data, it only processes a tiny part of it.