On Fri, Sep 02, 2011 at 10:52:17AM -0500, Nulik Nol wrote:
> >
> > 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
> > fra
>
> 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
On Thu, Sep 01, 2011 at 11:34:11AM -0500, Nulik Nol wrote:
> 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.
Most if not all (widely used) relational databases these days expose some type
> 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
On Wed, Aug 31, 2011 at 07:28:59PM -0700, William Ahern wrote:
> FWIW, the PostgreSQL C client API works non-blocking. It's quite well
> designed.
>
I wrote this years ago so mind the crappy code (not to mention pre
levent2), but it's a good example of how to use libevent + nonblocking
pgsql.
h
On 2011/9/1 10:28, William Ahern wrote:
On Wed, Aug 31, 2011 at 09:10:35PM -0500, Nulik Nol wrote:
I have searched quickly what database engine supports asynchronous io
and found quite a lot of good projects, one of them called Redis, it
is a sort of replacement for memcachedb. Nice stuff! Chec
On Wed, Aug 31, 2011 at 09:10:35PM -0500, Nulik Nol wrote:
> I have searched quickly what database engine supports asynchronous io
> and found quite a lot of good projects, one of them called Redis, it
> is a sort of replacement for memcachedb. Nice stuff! Check it out:
> http://redis.io/
>
> I th
>
> 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
On Wed, Aug 31, 2011 at 11:58:32AM -0500, Nulik Nol wrote:
> 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 asynchr
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
10 matches
Mail list logo
