postgres wont do preparedstatements

[Jan-Henrik Haukeland]

On 25. feb.. 2008, at 09.42, Paul J Stevens wrote:

> - finally, start doing the command processing in threads so the  
> database calls
> don't block the main thread anymore.

Yes, in a single threaded non-blocking i/o server, you must conduct  
database operations in a thread to avoid halting the server. The trick  
though is to do mostly CPU bound operations in the database thread and  
leave i/o bound operations to the libevent main thread. That way, it  
is possible to have a few threads in a pool handling many connections.  
But I guess you know that. I just completed a HTTP application server  
that does just that for HTTP requests/responses with database access,  
and I'm also using libevent and of course zdb. This architecture  
scales very well.

> I expect and hope that by combining libevent and libzdb we'll  
> achieve quite an
> interesting potential for scaling up the imap server. Both represent  
> very
> exciting technologies that fit very well with what I'm trying to do.
>
> After the above milestones have been completed, and if sponsoring is  
> found we
> might even add multiple connection pools in the mix so different  
> imap users are
> mapped to different database backends.

Good catch, I was about to suggest that. Its not obvious that it is  
possible to use several Connection Pool instances against different  
database back ends.

Good luck with the project!