On 9 Aug 2013 17:03, "Greg Stark" <st...@mit.edu> wrote: > I looked at the wiki and thought it had a lot of good ideas but also a lot of good questions. do you have any idea how to tackle the session problem? > [...] > A decent HTTP RPC layer will need to have some way of creating a session and issuing multiple requests on that session. That session will need to be a stored and available for future requests. The obvious concern is state like the current database, current role, gucs, and prepared queries. But even if you're prepared to discard those for a stateless interface the performance issues of not having a relcache built will be pretty severe.
The performance certainly will be poor to start with, yes. Sessions and HTTP simply don't go together, and so I think we need to accept that each request is going to be stateless. (We could use Websockets, and pass the socket to libpq.... but that hardly counts as an HTTP API.) 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. Regards, Andrew Tipton