in reply to Re: complex string matching
in thread complex string matching

but it slows down bulk-operations considerably.

As I understand it, this isn't quite right. It is slower for multiple transactions but single bulk transactions are faster than Pg and MySQL and since most operations are faster, SQLite comes off as the clear winner for speed: SQLite speed (see disclaimer on age of benchmarks and IANADBA).

Replies are listed 'Best First'.
Re^3: complex string matching
by locked_user sundialsvc4 (Abbot) on Nov 04, 2010 at 16:06 UTC

    Oh, no question at all about that.   And, no question that SQLite is doing exactly what it should.   But the difference can be quite dramatic (and of course, they stress to say as much.)

    SQLite is naturally very fast because it is writing directly to a file.   There is no IPC-protocol overhead no matter how slight.   But it takes a very cautious about ensuring that disk-writes really have happened.   And this slows the processing down to a speed that is determined by the rotation-time of the disk platter.   Whereas, if a transaction is in effect, it knows that it doesn’t have to do that.   Since client-server databases might handle write-commits in a different way (vis-a-vis what they do and don’t oblige the client to stop and wait for).   I meant it just as a little heads-up...

    SQLite is one of those software projects that makes you sit up and bow down.   A real, “holy smokes!! piece of software.   (Y’know, like Perl... and I mean that.)