<p dir="ltr"><br /> On 9 Aug 2013 17:03, "Greg Stark" <<a href="mailto:stark@mit.edu">stark@mit.edu</a>>
wrote:<br/> > I looked at the wiki and thought it had a lot of good ideas but also a lot of good questions. do you
haveany idea how to tackle the session problem?<br /> > [...]<br /> > A decent HTTP RPC layer will need to have
someway of creating a session and issuing multiple requests on that session. That session will need to be a stored and
availablefor 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
relcachebuilt will be pretty severe.<p dir="ltr">The performance certainly will be poor to start with, yes. Sessions
andHTTP simply don't go together, and so I think we need to accept that each request is going to be stateless. (We
coulduse Websockets, and pass the socket to libpq.... but that hardly counts as an HTTP API.)<p dir="ltr">For my
patch,I plan to use pre-forked bgworkers which have already connected to the backend, so that populating the relcache
andother process startup costs don't impact on the HTTP response time. (This still means queries are being planned and
functioncode is being compiled for each request, of course...)<p dir="ltr">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
andease-of-deployment.<br /><p dir="ltr">Regards,<br /> Andrew Tipton<br />
