[Metakit] Developer responsibilities vs other databases

[metakit at kaishaku.org]

> In my most recent testing, Metakit looks an impressive candidate to
> take over some work currently done by MSSQL (via Python+COM/ADO).
> 
> On the other hand, PGSQL looks good, but is not nearly as elegant.
> I wonder what it means to move from MSSQL/PGSQL but worry I might
> be losing something important I take for granted, especially with
> respect to data integrity and/or stability.
> 
> How do the responsibilities of a Python+Metakit developer differ
> from those of a Python+ADO/MSSQL developer? (or PGSQL)

How about SMP support, especially considering the near future
of computing with multi-core CPUs. Python people consider this
solved by adding processes, which may work ok for logic...

I know MSSQL does take advantage of multiple CPUs and assume
PGSQL is similar. I am guessing Metakit does not. Am I right?

If so, will that ever change? Under what set of conditions?

Ironically enough, the multi-process solution still depends on
data storage, often via a memory mapped file, to provide safe
and efficient data sharing/communication between processes.

That may be ironic because Metakit is more similar to these
memory mapped sharing techniques than MSSQL/PGSQL which DO
provide good support for SMP.

Will we simply assume people will "never need more than one
cpu" for desktop applications and leave it at that?

I should probably note that when doing heavy work in MSSQL,
I still have idle CPU cycles. However, the same is not true of
MetaKit doing the same work and this is on about the fastest x86
single-core hardware around, 2.5Ghz Athlon 64 (San Diego). I have
DDR500 RAM and 10k RPM hard drives. So, the CPU is already the
bottleneck for Metakit in my tests. Couple this with the likely
fact that single-cores may actually get slower for a while as
they are made to share space with other cores on a die, and
it seems MetaKit performance may be limited for a while...

This is a secondary consideration to my first concerning integrity.
I just wanted to make note of it... I understand it's a big deal
for many pieces of software, but I don't think it's too early to
start supporting or at least considering multi-core CPUs. After
all, I already left a multi-core machine for a faster single-core
to stave off any performance limitations in the multi-core dilemma
for at least a couple years.

-- 
 kai