Quoth [EMAIL PROTECTED] ("Andy Ballingall"):
> This is the future, isn't it? Each year, a higher percentage of DB
> applications will be able to fit entirely in RAM, and that percentage is
> going to be quite significant in just a few years. The disk system gets
> relegated to a data preload on startup and servicing the writes as the
> server does its stuff.

Regrettably, this may be something that fits better with MySQL, as it
already has an architecture oriented to having different "storage
engines" in behind.

There may be merit to the notion of implementing in-memory databases;
some assumptions change:

 - You might use bitmap indices, although that probably "kills" MVCC;

 - You might use T-trees rather than B-trees for indices, although
   research seems to indicate that B-trees win out if there is a 
   great deal of concurrent access;

 - It can become worthwhile to use compression schemes to fit more
   records into memory that wouldn't be worthwhile if using demand

If you really want to try this, then look at Konstantin Knizhnik's
FastDB system:

It assumes that your application will be a monolithic C++ process; if
that isn't the case, then performance will probably suffer due to
throwing in context switches.

The changes in assumptions are pretty vital ones, that imply you're
heading in a fairly different direction than that which PostgreSQL
seems to be taking.  

That's not to say that there isn't merit to building a database system
using T-trees and bitmap indices attuned to applications where
main-memory storage is key; it's just that the proposal probably
should go somewhere else.
output = ("cbbrowne" "@" "cbbrowne.com")
How does the guy who drives the snowplow get to work in the mornings?

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
      subscribe-nomail command to [EMAIL PROTECTED] so that your
      message can get through to the mailing list cleanly

Reply via email to