Re: [help] main memory db

From: Christopher Browne <>
Date: 2 Dec 2003 20:04:39 GMT
Message-ID: <bqir8m$22r2d9$>

Martha Stewart called it a Good Thing when "Marshall Spight" <> wrote:
> "Paul" <> wrote in message
>> I think that in memory dbs will start to become very common in the near
>> future.
> I think we'll start to hear a lot more hype about in-memory
> databases, yes. I'm not sure it'll be anything other than
> hype, though. To the best of my knowledge, many existing
> DBMS products use main memory just fine. It's just a question of
> tuning the parameters.
> I don't see how failing if your database exceeds main memory
> size is a particular virtue.

Well, there's the _possibility_ (I haven't seen good papers on it, so I rank it only as "possible") that there would be substantially different algorithms that you would use if you know you'll never be hitting disk.


If the behaviour of T-trees leads to data being accessed in substantially different ways than happens when walking a B-tree cache, then there may be _specific_ merit to "in-memory" as distinct from hooking up lots of cache to a more traditional RDBMS.

The claim of in-memory DBMS vendors is that it _is_ faster to have it all managed in memory than to have buffer caches in the way.

  • The paper points to the costs of managing cache, that seem legitimate.
  • But perhaps clever RDBMS implementors can, albeit at the cost of some complexity, improve how well they manage cache.

  [There's a significant ongoing effort in that regard right now    with PostgreSQL; improved buffer management code is being    actively worked on...]

I can't tell how much of it is reality, and how much is hype. I daresay I _refuse_ to believe what in-memory vendors tell me, because I know it is in their interests to twist things to look favorable for their position. I don't know of 'objective' work on the matter.

wm(X,Y):-write(X),write('_at_'),write(Y). wm('cbbrowne','').
As of next Tuesday NCOMPLR will no longer open-code arithmetic statements.
Please update your programs.
Received on Tue Dec 02 2003 - 21:04:39 CET

Original text of this message