>
> Crap, I just realized this is completely off topic - but my main point
> is to gather requirements, and make a determination if you're willing to
> risk flexibility for possible bumps in performance. Or just abstract the
> frakk out of your query API so that it can be swapped out transparently
> FWIW, the PostgreSQL C client API works non-blocking. It's quite well
> designed.
>
Thanks!
But ... I think it is over for me with SQL type databases. There is a
big movement going on on non-relational databases and I think it is
time to change.
I came across GT.M database. It was commercial but
>
> Beware: once you read thru the MySQL code you'll never want to use MySQL
> again ;) The apparent robustness of MySQL has little to do with the quality
> of the code and everything to do with the millions of people banging on it
> every day.
> particular scenario. YMMV. Also, I'm not familiar w
Hi,
I was wondering if someone has managed it to adapt mysql client's C
API to work asynchronously ?
As far as I have checked, MySQL (5.6.2) uses libevent for server, but
not for the client. The only way to achieve sort of asynchronous
behaviour is to use pthreads and spawn one thread per connectio
