Re: how to build a database from scratch
Date: Fri, 08 Dec 2006 23:01:19 GMT
Message-ID: <39meh.449886$5R2.256116_at_pd7urf3no>
DBMS_Plumber wrote:
> paul c wrote:
>
>
>>This is getting further and further away from the original question (at >>least the single answer "use a btree" to the original question) which I >>understood to be - does a BTREE algorithm need to change to allow >>concurrency. The answer is no if tasks or processes independent from >>the btree ones are used, eg., a logical lock manager (one that locks >>values, not blocks) and a transaction's updates are flushed together.
>
>
> Please look up "Halloween Problem".
>
> Having understood it, explain please how you can solve it with a
> logical lock manager and by flushing updates.
>
> Please look up "Concurrency Tree Locking".
>
> Having understood it, explain how it can be implemented with a logical
> lock manager and by flushing updates.
>
> There are perhaps a score of other challenges that apply at the purely
> physical level of B-Tree implementations which I could rabbit on about.
Which you are destined to do if you persist in suggesting that the btree layer of a multi-user dbms should be allowed to issue Get's or StartIO's or mallocs or locks of any kind. If a btree process or task is ever aware that it is waiting, its dbms will be a mess from the start.
> For these reasons, none of the world's commercial B-Tree
> implementations employs the naive B-Tree algorithms as anything more
> than a rough outline.
I know first-hand that isn't true, but I haven't time to get into product details, unless somebody is willing to pay me for it. Perhaps more experience will encourage less categorical statements than the above. They are a disservice to the casual readers here.
There was a time when the so-called dbms's operated with virtually no memory and much of the present so-called implementation theory reflects that which is a shame. Meanwhile there is very little innovation to distinguish the current popular products when it comes to physical operation and this is even more true in the more fertile area of logical behaviour. I knew one advanced product, eg., it had a predicate lock manager long before any of the big-name dbms'es, that was designed to eliminate dba's. Sales were abysmal, in part because dba's in big corporations saw this as a big threat and did every thing they could to keep the product out. Eventually all kinds of knobs and utilities were added, most of which had no other function than to provide jobs for the boys, after which sales improved.
p Received on Sat Dec 09 2006 - 00:01:19 CET