Re: Hashing for DISTINCT or GROUP BY in SQL

paul c <anonymous_at_not-for-mail.invalid> writes:
> Later I met an Amdahl salesman who said, "give me more of this
> relational stuff, I can sell all the 'boxes' it needs". When a boss
> of mine plunked for an Amdahl cpu, the local IBM field manager invited
> him over for coffee and 'career counselling'. That was in the
> mid-1980's. By the early 1990's even IBM could see which way the wind
> was blowing and introduced the RS6000, basically a Unix machine, an
> attempt to hedge their bets, having already blown their early PC
> lead. In other words, just like other people do now, they knew
> something big was happening, they just didn't know what.

lots more complicated than that.

I knew many of the people at amdahl ... including the guy doing the amdahl dbms HURON.

801/risc was "invented" by john cox in the 70s ... I've claimed that it was attempting to go to the opposite extreme of the (failed) future system project ... some past future system posts http://www.garlic.com/~lynn/submain.html#futuresys

around 1980 there was effort to converge the large variety of different internal microprocessors to 801 (iliad) ... controller microprocessors, microprocessors used for low & midrange mainframes, microprocess for the s/38 followon ... the as/400, etc. For various reasons that effort failed ... and some number of engineers left and show up at other vendors working on risc efforts. there was the OPD joint effort with research for ROMP and the displaywriter followon. For various reasons that got canceled and group looked around for something else to do with the hardware ... and hit on the unix workstation market ... eventually releasing the PC/RT with AIXv2 (they hired the group that had done the port of unix to the pc ... to do a port to pc/rt). the group then worked on followon chip to ROMP ... called RIOS ... which was eventually announced and shipped as RS/6000 workstation with AIXv3. misc. past posts mentioning 801, risc, romp, rios, pc/rt, iliad, rs/6000, etc. http://www.garlic.com/~lynn/subtopic.html#801

note that while risc/Iliad floundered and various cisc chips were done, including for the as/400 ... as/400 did finally move to 801/risc (power/pc) chip in the 90s.

in the mid-80s timeframe I had done some work on putting large number of (801) "blue iliad" chips into large number of racks for various kinds of dataprocessing. "blue iliad" was never finished. However, with rios ... I started project to do the ha/cmp product along with cluster scaleup. some old email related to cluster scaleup http://www.garlic.com/~lynn/lhwemail.html#medusa

where there was lots of work on cluster scaleup to address both commercial as well as numerical intensive (supercomputer) markets. old post mentioning early jan92 meeting in ellison's conference room on RDBMS scaleup.
http://www.garlic.com/~lynn/95.html#13

however in that time frame, the corporate supercomputer effort was out looking for technologies and discovered what we were working on.

possibly within hours of this email
http://www.garlic.com/~lynn/2006x.html#email920129 01/29/92 email,

the effort was transferred, we were told we couldn't work on anything with more than four processors, and within couple weeks there were articles: http://www.garlic.com/~lynn/2001n.html#6000clusters1 02/17/92 "scientific and technical *only*"

and then later
http://www.garlic.com/~lynn/2001n.html#6000clusters2 06/19/92 "caught by *surprise*"

there was some folklore that commerical mainframe dbms group didn't mind because what I was doing was possibly five years ahead of where they were at. i had also been asked to write a section for the corporate continuous availability strategy document ... but it was pulled when both rochester (as/400) and pok (mainframe) complained (that they couldn't meet the objectives). I had coined the terms "disaster survivability" and "geographic survivability" (to differentiate from disaster/recovery) when I was out marketing ha/cmp ... some past posts mentioning availability
http://www.garlic.com/~lynn/submain.html#availability

there is also some folklore that the distributed lock manager I had designed for ha/cmp was reverse engineered and used by some rdbms for cluster operation on other vendor platforms.

part of the cluster rdbms was working with various rdbms vendors that had both vax/cluster as well as unix implementations. some of the ha/cmp distributed lock manager was done to ease migration of their vax/cluster support over onto unix platform (one such rdbms vendor did contribute the list of the top ten things wrong with the vax/cluster distributed lock manager ... that needed fixing).

a couple items from oct2009
http://freedb2.com/2009/10/10/for-databases-size-does-matter/ http://www-03.ibm.com/press/us/en/pressrelease/28593.wss

which led me to post some comments "From The Annals of Release No Software Before Its Time"
http://www.garlic.com/~lynn/2009p.html#43 http://www.garlic.com/~lynn/2009p.html#46

misc. past posts mentioning original relational/sql implementation system/r
http://www.garlic.com/~lynn/submain.html#systemr

there first was tech. transfer of system/r from bldg. 28 to endicott for sql/ds. one of the people mentioned in the ellison conference room meeting claimed to have handled much of the tech transfer from endicott to STL for (mainframe) db2.

a completely different rdbms ... originally called shelby ... done in C-language in Toronto for OS/2 ... was eventually announced for non-mainframe platforms as DB2 (also ... although it was/is a completely different implementation).

-- 
virtualization experience starting Jan1968, online at home since Mar1970