Re: how to build a database from scratch

Sampo Syreeni wrote:
> On 2006-12-07, paul c wrote:
>

>> A strict internal separation, eg., protocol will allow multiple NAIVE 
>> btree tasks to co-exist.

>> All the rest is depends on the speed of hardware.

The implementation I was familiar with was simple and fast. Physical pages were fed to logical access tasks that performed queries and updates solely to memory. Logical tasks would wait for physical pages if they were not in cache. Query tasks obeyed a strict 2PL protocol and multiple table updates were ordered to prevent deadlock. I suspect this kind of scheme is common, it requires several asynchronous components, eg., disk manager, commit/log manager, cache manager, checkpoint manager. From many real-world applications, I observed that performance would be unchanged if much of this plumbing were eliminated and user queries/updates were queued by a single task that operated only on memory and had a fast log in case of physical crashes. There was a small minority of applications that weren't amenable to a simpler system. Simpler systems should be the goal, they are almost always stronger, safer and more economical.

(BTW, I don't understand why some DBMS people are so interested in parallel processors, they are mainly the hardware manufacturers' reaction to the increasing gap between processor and memory speeds. Not many real applications need parallel hardware.)

p Received on Thu Dec 07 2006 - 15:55:28 CET