Re: A better SQL implementation?

From: David Cressey <>
Date: Fri, 09 Jun 2006 12:17:34 GMT
Message-ID: <yFdig.6684$LN1.6581_at_trndny01>

"paul c" <> wrote in message news:0I3ig.1084$Wz4.762_at_pd7tw2no...
> David Cressey wrote:
> > ...
> > If I go back twenty years, I was dealing with Rdb/VMS. Rdb/VMS was
> > certainly capable of using more than one index to resolve a single
query. I
> > can't believe that someone who worked on the original system-R would
fail to
> > know both Rdb/VMS and, more importantly, the algorithms the strategy
> > generator uses to propose alternatives.
> > ...
> Maybe I should have said thirty years. For sure in both eras, everybody
> and his brother worried about seek times and rotational latencies almost
> to the exclusion of everything else. Come to think of it I was aware of
> products (non-relational) that exploited all indexes before they went
> after "rows".
> By the way, when I was talking about transactions in a low-level DEC
> access method (in some other thread here - you thought it might have
> been RMS) my memory was playing tricks on me. Credit where credit is
> due - the access method (whose name I still forget) was built in to
> WANG/VS, not a DEC offering. The transaction support (which was a
> requirement of the product I was using) was a walk in the park compared
> to drivers for other platforms, eg. VSAM, that I had to prototype.
> p

Don't know much about WANG. I recall that someone from the TOPS-10 group moved over to WANG. It might have been Tony Wachs.

Interesting that you had to provide transaction support.

DEC Rdb/VMS engineers were NOT overly obsessed with seek times and rotational latencies. If anything, Rdb databases tended to get slowed down by letting the disks they resided on get fragmented, even though there were easy counter measures for a system manager to take. Generally, it was a symptom of bad working relationships between system managers and DBAs. Received on Fri Jun 09 2006 - 14:17:34 CEST

Original text of this message