Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uwm.edu!ux1.cso.uiuc.edu!midway!clout!chinet!dhartung
From: dhartung@chinet.chi.il.us (Dan Hartung)
Newsgroups: comp.databases
Subject: Re: The Rushmore Technology from FoxPro
Message-ID: <1991Jun07.060129.7177@chinet.chi.il.us>
Date: 7 Jun 91 06:01:29 GMT
References: <1991Jun1.165211.27480@ugle.unit.no>
Organization: Chinet - Chicago Public Access UNIX
Lines: 89

oysteing@idt.unit.no writes:
>A few months ago I got a demonstration of the 'revolutionary',
>according to an ad from FoxPro, Rushmore Technology. I am interesting
>in hearing some comments from people that have had some experience
>with it.

Certainly.  As a FoxPro developer I have some insight into this 
subject.   :-)

>From what I could see, the query performance was much better than what
>I have experienced with ORACLE/INGRES, but we only got an limited
>demonstration.

They are claiming that it beats DB2 on an AS/400 operating on an identical
one-million-record database.  I think this was on a 386 machine; have to
check my papers.
>
>My impression was that the technology is based on some technique where
>indexes occupy much less space than usual. Thus, it is possible to
>index all fields of a table and keep all indexes in memory. This way
>queries can be processed with a minimum of disk access. Is this your
>impression, too?

Compact indexes are one of the featurs of the new FoxPro.  In and of
themselves, however, they don't constitute the RushMore technology.
What they are doing is using indexes with a number of commands that
previously did not use the indexes:  xBase LOCATE and COUNT commands,
for instance.   Thus it is helpful to have as many indexes open as
possible; and the compact index format helps this be efficient.

>I seem to remember reading on this group that FoxPro needs a lot of
>memory. What happens if all indexes does not fit into memory? Is there
>a significant decrease in performance?

FoxPro operates impressively well for an xBase product on even a 640K XT.
When you give it extra memory, though, it takes off.  It makes automatic
used of expanded memory; Fox 2 will use extended automatically, but now
you have to use a (well-behaved) EMS emulator if you only have extended.
Fortunately RAM is cheap.  Fox 2 will have a much more granular overlay
and an LRU algorithm for swapping program segments to disk, something
like VROOOOM from Borland.

>The table used for the demonstration consisted of only character
>fields. Does an index of an integer field take much more space than an
>index of a character filed? As you probably know, you can usually
>compress text much more than numbers (Huffman code, Tries etc.)

xBase is not very good with number fields.  In general numbers are best
stored as a character representation anyway.

>We only got a demonstration of selection from one table. How is the
>performance on joins?

The SQL-mode performance is supposed to be very good, due to the 
compact indexes and Rushmore.  I don't know how it matches up against
Paradox, say, but it surely beats dBase IV's clunky implementation.
Most amazing, FoxSQL allows full user-defined function use in SQL.

Third-party vendors will be implementing connectivity links to SQL
servers, and Fox is working on Fox Server for '92.
>
>Do you think the Rushmore Technology is really revolutionary?

Depends.  It is certainly a big step forward for xBase, but I don't know
if it is really something new to other RDBMS platforms.  What seems to
be the case is that the combination of raw power now available cheaply
in the PC world, combined with a superb RDBMS (FoxPro) is going to result
in a new generation of powerful databases.
>
>As memory gets cheaper, it will maybe be possible to store large
>amounts of data in memory for faster query processing. This will
>significantly increase the query performance. Do you think this will
>cause great changes in the DBMS-market?

I don't think it will really change things, since the memory-for-query-
processing is more or less need-driven.  That is, the need for this
kind of hardware optimization is there already, the only question is
how fast can the software to implement it get there?
>
>Oystein Groevlen 
>Division of Computer Systems and Telematics 
>The Norwegian Institute of Technology The University of Trondheim
>Email: oysteing@idt.unit.no

How is Norway?  I was in Oslo in '86 and really enjoyed my visit.......
-- 
Daniel A. Hartung           |  "What's the difference anyway, between being
dhartung@chinet.chi.il.us   |  safe and being rad, the joke's on us, we've
Birch Grove Software        |  all been had."  -- John Wesley Harding