At 10:18 AM 15-10-2001 -0400, Tom Lane wrote:
>Lincoln Yeoh <lyeoh@pop.jaring.my> writes:
>> Create a small program that makes a few connections to postgresql, does
>> some initialization, preconnects to various DBs (or maybe limited to one DB
>> specified on startup), and listens on one port/socket. It might not even
>> prefork, just cache connections so first connection is slow, subsequent
>> ones are cached along with the user-pass for faster authentication.
>
>> Then your apps can connect to that small program, authenticate, and get the
>> relevant connection. Call it a "Listener" if you want ;).
>
>Couple of problems...
>
>(a) where is this outside program going to get authentication
>information from?
Various options:
1) No authentication required by client - authentication supplied on
startup/config.
2) Local authentication - runs as postgres user, reads from postgres files.
3) Local authentication - from config file, mapped to actual remote
authentication
4) Authentication from remote server, then cached in memory.
>(b) it seems that not only the authentication exchange, but also all
>subsequent data exchange of each connection would have to go through
>this additional program. That middleman is going to become a
>bottleneck.
The authentication exchange doesn't happen that often, since the DB
connections are reused - no reconnection.
True it might be a bottleneck. But in certain setups the middleman is not
running on the DB server and thus not using the DB server resources.
---
Are there really compelling reasons for having a preforking backend? What
would the benefits be? Faster connection setup times? Connecting and
disconnecting quickly is important for a webserver because of the HTTP
protocol, but for a DB server? Would it really be fast in cases where
there's authentication and access control to various databases?
Perhaps it's undesirable for people to roll their own DB connection
pooling. But my worry is that there's such a great diversity that most
people may still have to roll their own DB connection pooling, then a
preforking backend just adds complexity and sucks up a bit more resources
for little gain.
For example in my case if connection setup times are a problem, I'd just
preconnect and reuse the connections for many transactions. Wouldn't that
still be much faster than a preforking backend? How fast would a preforking
backend be?
Regards,
Link.