Tom Lane:
> Meanwhile, *I* missed the point about Brett's second comment :-(
>
> Brett McCormick <brett@work.chicken.org> writes:
> > There will have to be some sort of arg parsing in any case,
> > considering that you can pass configurable arguments to the backend..
>
> If we do the sort of change David and I were just discussing, then the
> pre-spawned backend would become responsible for parsing and dealing
> with the PGOPTIONS portion of the client's connection request message.
> That's just part of shifting the authentication handshake code from
> postmaster to backend, so it shouldn't be too hard.
>
> BUT: the whole point is to be able to initialize the backend before it
> is connected to a client. How much of the expensive backend startup
> work depends on having the client connection options available?
> Any work that needs to know the options will have to wait until after
> the client connects. If that means most of the startup work can't
> happen in advance anyway, then we're out of luck; a pre-started backend
> won't save enough time to be worth the effort. (Unless we are willing
> to eliminate or redefine the troublesome options...)
I was thinking that we would have a pool of ready servers _per_database_.
That is, we would be able to configure say 8 servers in a particular DB, and
say 4 in another DB etc. These servers could run most of the way through
initialization (open catalogs, read in syscache etc). Then they would wait
until a connection for the desired DB was handed to them by the postmaster.
-dg
David Gould dg@illustra.com 510.628.3783 or 510.305.9468
Informix Software (No, really) 300 Lakeside Drive Oakland, CA 94612
"Of course, someone who knows more about this will correct me if I'm wrong,
and someone who knows less will correct me if I'm right."
--David Palmer (palmer@tybalt.caltech.edu)
