btree on disk

JdeBP> Actually, the Bernstein approach to this would be to not
JdeBP> reinvent the filesystem. The filesystem is quite capable
JdeBP> of holding three parts of a web page to be concatenated
JdeBP> together, in three files. The rename() system call provides
JdeBP> atomic update semantics for individual parts, if one
JdeBP> requires those. And directories provide indexing.

WA> I agree. I'm guilty of not paying sufficient attention to the
OP's
WA> request. But also I've given up on this fight. I've been railing
WA> against gratuitous use of SQL databases and other useless
WA> data obsfucations for years, but often you just get some
WA> micro-benchmark thrown back in your face; eventually you
WA> just get worn down.

JdeBP> Witness the operation of the Maildir mailbox format.

WA> You haven't met the developer of UW-IMAP, yet, have you?
WA> Watch out for useless micro-benchmarks. ;)

RW> The 'developer of UW-IMAP' never provided a 'micro-
benchmark' [...]

True. However several benchmarks _were_ produced in response. Here
are some: people.redhat.com./rkeech/maildir-migration.txt> www.decisionsoft.com./pdw/mailbench.html>

(And although I haven't physically met M. Crispin, I've been around
for a long time, and I do know who he is. I cited him in one of my
FGAs back in 2004.)

Re: btree on disk

J de Boyne Pollard wrote:

> WA> You haven't met the developer of UW-IMAP, yet, have you?
> WA> Watch out for useless micro-benchmarks. ;)

> RW> The 'developer of UW-IMAP' never provided a 'micro-
> benchmark' [...]
>
> True.

Not true. Crispin made reference to benchmarks which ostensibly supported
the declaration. That he--or somebody else--didn't see fit to publish them
is beside the point. And given the description, there's IMO sufficient
evidence with which to base my criticism, especially in light of the
benchmarks below.

> However several benchmarks _were_ produced in response. Here are some:
> > people.redhat.com./rkeech/maildir-migration.txt> > www.decisionsoft.com./pdw/mailbench.html>