Re: Connection pooling.

Philip Warner <pjw(at)rhyme(dot)com(dot)au> writes:
> What stops the interface library from using the host & port to talk to
> the postmaster, find the host & port the spare db server, then connect
> directly to the server?

You're assuming that we can change the on-the-wire protocol freely and
only the API presented by the client libraries matters. In a perfect
world that might be true, but reality is that we can't change the wire
protocol easily. If we do, it breaks all existing precompiled clients.
Updating clients can be an extremely painful experience in multiple-
machine installations.

Also, we don't have just one set of client libraries to fix. There are
at least three client-side implementations that don't depend on libpq.

We have done protocol updates in the past --- in fact I was responsible
for the last one. (And I'm still carrying the scars, which is why I'm
not too enthusiastic about another one.) It's not impossible, but it
needs more evidence than "this should speed up connections by
I-don't-know-how-much"...

It might also be worth pointing out that the goal was to speed up the
end-to-end connection time. Redirecting as you suggest is not free
(at minimum it would appear to require two TCP connection setups and two
authentication cycles). What evidence have you got that it'd be faster
than spawning a new backend?

I tend to agree with the opinion that connection-pooling on the client
side offers more bang for the buck than we could hope to get by doing
surgery on the postmaster/backend setup.

Also, to return to the original point, AFAIK we have not tried hard
to cut the backend startup time, other than the work that was done
a year or so back to eliminate exec() of a separate executable.
It'd be worth looking to see what could be done there with zero
impact on existing clients.

regards, tom lane