Re: [exim] Exim 5 Wishlist

Wouter Verhelst wrote:
> On Fri, Feb 16, 2007 at 04:56:53AM +0800, W B Hacker wrote:
>> Richard Pitt wrote:
>>> SQL generally requires far
>>> more resources for similar performance - especially with "blobs" of any
>>> size.
>> Not 'generally'. 'Always'. And by a large margin.
>>
>> At the end of the day any DB must *also* map to the underlying fs -
>> and not just the raw data - but all of its own overhead, logs, checks
>> and balances, bells and whistles.
>
> You're oversimplifying here. Kernels have the ability to switch off
> caching (O_DIRECT, etc), metadata-updates, and similar, for specific
> files, and database servers generally use those APIs.

Some may (kernels and/or DBMS).

Those most commonly used by the Exim community are not high on that list, and/or
that level of sophistication is seldom pursued by the sysadmins (MySQL,
PostgreSQL, SQLite more often than DB2, Oracle, IMS).

'oversimplifying' is mere pragmatism, in this case.

>
> It's also perfectly possible in some cases to run a database directly on
> a raw device ('/dev/XXX'), and bypass the filesystem entirely.
>

Not really. That is just letting the DBMS create its own file system
'equivalent'. TANSTAAFL

> Finally, if you run a mail store on a filesystem, you usually require
> many files -- exim requires two files per mail in the mail store. Most
> database systems dump all their tables in one file, so the stress on the
> filesystem implementation isn't as extensive.
>

Not. A DB doesn't necessarily even write as 'lean' a total file OR byte-count as
Exim, best-(DB) case.

Tables are by no means the only thing that must be written.

Some may operate with just one file, but as in the case of use of the 'raw block
device' it is effectively a 'container' file, ergo needs a good deal more
manipulation than just appending raw relations and tuples.

Think storage/recovery for logs, timestamps, progress information, indices,
perms, connection status, scratch files for sorts and merges, et al - even if
there is no commit/rollback transactionalism.

> Not that I think using a database server as a mail store is a
> particularly good idea, but that's a different matter entirely.
>

It is not as if there was no prior art.

The curious should go and look at the now-rather-longish history of DBMail and
PowerMail, just to name two.

Both are niche apps, and there is nothing magical there to drive Exim in that
direction.

Especially since those two already exist, and are easily modifiable, DB-wise.

Bill