Hello, Steve 2014-09-10 21:08 GMT+04:00 Steve Atkins <st...@blighty.com>:
> > On Sep 10, 2014, at 12:16 AM, Dmitriy Igrishin <dmit...@gmail.com> wrote: > > > Hello, David > > > > 2014-09-10 4:31 GMT+04:00 David Boreham <david_l...@boreham.org>: > > Hi Dmitriy, are you able to say a little about what's driving your quest > for async http-to-pg ? > > I'm curious as to the motivations, and whether they match up with some > of my own reasons for wanting to use low-thread-count solutions. > > For many web projects I consider Postgres as a development platform. > Thus, > > I prefer to keep the business logic (data integrity trigger functions and > > API functions) in the database. Because of nature of the Web, many > concurrent > > clients can request a site and I want to serve maximum possible of them > with > > minimal overhead. Also I want to avoid a complex solutions. So, I > believe that > > with asynchronous solution it's possible to *stream* the data from the > database > > to the maximum number of clients (which possible can request my site > over a > > slow connection). > > That's going to require you to have one database connection open for each > client. If the client is over a slow connection it'll keep the database > connection > open far longer than is needed, (compared to the usual "pull data from the > database as fast as the disks will go, then spoonfeed it out to the slow > client" > approach). Requiring a live database backend for every open client > connection > doesn't seem like a good idea if you're supporting many slow concurrent > clients. > Good point. Thus, some of caching on the HTTP server side should be implemented then. -- // Dmitriy.
