[kdepim-users] changing database backend

Pablo Sanchez pablo at blueoakdb.com
Wed Nov 12 15:57:23 GMT 2014

[ Comments below, in-line ]

On 11/12/2014 10:40 AM, René J.V. Bertin wrote:
> On Wednesday November 12 2014 09:54:20 Pablo Sanchez wrote:
> Hi

Hi René

> with a 300Gb harddisk that isn't likely to be the bottleneck;

If you don't believe your HDD is the source of your bottleneck, then
why change the backend DB and talk about disabling the database's
logging facility?

In my experience though, you'll find an instant performance boost
moving to an SSD.  You'll of course become CPU bound but that's
/generally/ a good problem to have.

> an SSD upgrade for that kind of machine is just not reasonable).

I bought a 500+ GB SSD for my old laptop.  The SSD is worth more than
the laptop.   :)   I plan on re-using the SSD on a subsequent

> Yes, I've seen that. It's something akin to COW, and with ZFS's own
> COW plus the copies=2 I'm running with that would just be too much
> redundancy. 

It's not quite as simple as you're stating:  "too much redundancy."

An ACID compliant DBMS moves from one consistent state to the next.
It uses its logging/journal facility for this.  The logging facility
is synchronous.  That is, the caller will not be allowed to continue
until the data is persisted to disk.

If we instruct the DBMS to use non-synchronous and/or buffered writes,
then while it may believe its data is secure on disk, it may not be.

What this means is in the event of data loss to its journal (which is
used during crash-recovery), the DBMS will not be able to bring the
database back to a consistent state.  This means you're only recourse
is to recover the database from either the last full back up or the
last full backup plus any logs.

The above gets more complicated when you have multiple connections to
the database, each with complicated transactions.

Again, if you're willing to tolerate the potential of some data loss
and/or an inconsistent database (you'll have to re-create your entire
environment), then disable the DB's logging facility.

If in fact you're I/O bound, I'd suggest instead getting the SSD and
know you'll eventually re-use it on your next computer.  :)

>> >In order for the DBMS to conform to ACID [1], you can't disable
>> >logging.  :)
> But logging is independent of double-write, right?

No, it's not.

> Thanks for the links.

You're welcome.
Pablo Sanchez - Blueoak Database Engineering, Inc
Ph:    819.459.1926         Blog:  http://pablo-blog.blueoakdb.com
iNum:  883.5100.0990.1054

KDE PIM users mailing list
Subscription management: https://mail.kde.org/mailman/listinfo/kdepim-users

More information about the kdepim-users mailing list