Re: Deferred constraint checking
Date: Thu, 03 Aug 2006 17:55:30 GMT
Message-ID: <mMqAg.309710$Mn5.116008_at_pd7tw3no>
Roy Hann wrote:
...
>> http://www.oracle.com/technology/oramag/oracle/03-nov/o63asktom.html
>
> Thanks vc, but I think my request was insufficiently clear. What I am
> actually interested in is the underlying machinery that implements the
> described behaviour. For example, I want to know how these products track
> which rows will be checked when a deferred constraint is finally tested.
> (This might be a proprietary secret in many cases, but perhaps some of it is
> in the public domain, e.g. patent documents.) I would be particularly
> interested in the implementation details of deferred general constraints
> (assertions).
>
> Roy
>
>
'Initially deferred' and 'initially immediate' indeed! Sorry no answer from here but it all seems entertainingly human and pathetic at the same time. Reminded me of an article a boss once made us read (forget where but it was by a Harvard biz school prof), about how the purpose of the jet engine was perverted by its implementations which became more and more complicated, not because the purpose wasn't understood but because commercial passengers demanded air-conditioning and so forth. Also the local city council which wasted several hours of a recent public meeting trying to decide the difference between 'defer' and 'refer'.
I'd bet that these SQL phrases end up being perverted by implementations, eg., 'immediate' might be tested by several different components, some logical and some physical and 'deferred' by only physical ones. The complexity of packaging components might easily result in contradictions assuming different departments write the code for different components. Left hand, right hand ...
It may seem unrelated, but I've been reading papers by a smart guy named Lomet who's been around and is now at microsoft, about a fairly new mismatch - cpu cache's introduced because of the disparity between modern processor and memory speeds. Seems everybody is trying to hide the problem, Intel by adding various gizmos and the db people by changing their algorithms. Somewhere he mentions that thousands of potential cpu instructions can be lost forever by a cache miss. So how come the OS people aren't adding cache misses to the events that allow task pre-emption? I suspect the answer is that a thousand cycles doesn't buy what it used to buy, because all the 'convenience' software layers in today's products hide the original requirements.
p Received on Thu Aug 03 2006 - 19:55:30 CEST