Philip Warner <pjw@rhyme.com.au> writes:
> At 22:59 9/07/00 -0400, Tom Lane wrote:
>> I believe that the problem is on the backend side: there's an awful lot
>> of cache-initialization and so forth that happens each time a backend
>> is started. It's quick enough to be hard to profile accurately,
>> however, so getting the info needed to speed it up is not so easy.
> You could pre-start servers (ala Apache), then when a connection request
> comes in, the connection should be pretty fast. This would involve
> defining, for each database, the number of servers to prestart (default 0),
Yeah, that's been discussed before. It seems possible if not exactly
simple --- one of the implications is that the postmaster no longer
listens for client connections, but is reduced to being a factory for
new backends. The prestarted backends themselves have to be listening
for client connections, since there's no portable way for the postmaster
to pass off a client socket to an already-existing backend.
And of course the major problem with *that* is how do you get the
connection request to arrive at a backend that's been prestarted in
the right database? If you don't commit to a database then there's
not a whole lot of prestarting that can be done.
It occurs to me that this'd get a whole lot more feasible if one
postmaster == one database, which is something we *could* do if we
implemented schemas. Hiroshi's been arguing that the current hard
separation between databases in an installation should be done away
with in favor of schemas, and I'm starting to see his point...
regards, tom lane
