Re: question about HTTP API

On 9 Aug 2013 17:03, "Greg Stark" <stark(at)mit(dot)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