> For my patch, I plan to use pre-forked bgworkers which have already
> connected to the backend, so that populating the relcache and other process
> startup costs don't impact on the HTTP response time. (This still means
> queries are being planned and function code is being compiled for each
> request, of course...)
>
> This is going to be a very long series of patches, but IMHO we have to
> start somewhere! For some applications, performance is far less important
> than ease-of-use and ease-of-deployment.
Agreed. Too bad you can't do this as an extension, it would allow you
to rev releases a lot faster than once a year.
Actually, maybe you should look at "what is the minimum patch required
to enable a webserver extension", with the idea that most of the
webserver code would still live outside the core? That way you could
continue to develop it a lot faster.
Also, if all aspects of the web services model (management of sessions,
sercurity, etc.) need to be a core PostgreSQL patch, you're in for a
really long set of arguments since there's no one "best" way to do these
things. Keeping the web services engine outside the core would let you
not have those arguments on this list, which otherwise would likely
cause the feature to miss 9.4.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com