Re: New HDB backend MDB

On Wed, Dec 7, 2011 at 2:05 PM, Howard Chu <[email protected]> wrote:
> Nico Williams wrote:
> I use subdatabases in MDB for multiple tables, so no, just one file is used.

Great!

> Yes, that's what gave me the idea for the MDB port. And yes, SQLite3's
> overall architecture is a mess, no well defined abstraction layer
> boundaries, app-level code that's fully aware of the binary file format.
> Ugh.

It's not entirely a mess, and they seem to be improving things in the
long term.  But I'm annoyed at the low performance of the VM (and the
lack of stability of the VM, which makes it not remotely suitable as
an interface).

>> Depending on the filesystem you may be able to safely do just one sync
>> per-transaction.
>
> That would require that the filesystem writes to disk in exactly the order
> that the app issues write() calls, with no reordering. Since you can't
> guarantee that the hard drives themselves won't do seek
> optimization/reordering, I don't believe you can make that statement.

You have a single writer and a COW approach, so the only concern is
that the ubberblock not be written until the rest is written.

> NOSYNC is exposed. I may add NO_METASYNC.

An option to only sync after the ubberblock is written is what I'm
recommending :)

> mmap the whole DB, size is limited by the virtual address space. That was
> already spelled out in my presentation. And right, anyone doing serious
> server work is on 64-bit by now.

Agreed.

Overall I really like this.  I've not looked at the code, but I expect
I'd be pretty happy :)

One more question: is the page size configurable?  If not, what is the
page size?  If yes, what's the default page size and how can it be set
to a specific value?

Nico
--