Conference ulysse::rdb_vms_competition

    What I know about the subject is only what I read...
    
    Maybe someone with first hand experience, or a better understanding 
    of Ingres products could supply more information.
    
    From what I understand both Oracle and Ingres support location
    transparency for read-only transactions.  
    
    With Ingres latest Ingres/Star announcement (Digital Review Aug,13)
    Ingres Star now gives Ingres distributed two-Phase commit and location
    transparency across Ingres dataabases for read and write transactions.
    
    In the past Ingres was criticized, because their two-phase commit
    protocol did not do automatic recovery.  It appears from this quote
    that the new version of Ingres Star 6.3 (which version of 6.3 i'm not
    sure) now has automatic recovery.
    
        "The [updated] system does automatic recovery" Horst added.
        "If your in the middle of a five-node transaction  and one of the
         node fails at any time. [Ingres/Star 6.3] will either back out
         or recommit the transaction"
    
                                        Ed Horst
                                        Director of Product Marketing Ingres   
    
    
    It also appears from the following quotes that Ingres Star 6.3 gives
    location transparency.
    
        "Ingres/Star is a product that exist separatly from the Ingres
         database to offer location transparency, transaction transparency,
         [so that you can perform transactions helter skelter across
         different databases] and performance transparency so that
         performance so that performance is roughly equivalent acrost thoes
         databases"  horst said.
    
         It's transparent to users so that they don't have to write
         additional code, and if you decide to split the database
         application [to run it] on multiple databases, the program does
         not have to change.
    
         I would be interested in hearing if anyone had experience using
         this latest version of Ingres/Star 6.3 .  What are its strengths
         and limitations.  
                                                                         

Location Transparency is a neat thing to have, but without a global query 
optimizer, I would submit that it is just that -- a nice thing to have but I
probably would not use it.

Take the example where the employees is distributed over 4 systems by site code
and these systems are located in LA, Chicago, Boston and London.
Here I am sitting here on my workstation and I query the personnel database for
all employees where id  between 100000 and 200000.  Well the most optimizers
read each db seeking those ids and return all of them to my workstation.  That
is not too bad.  Now extend that query such that you do a join over salary 
history.  Since Salary History is normally a corporate thing, they will 
generally be stored at corporate.  What most systems do that have location 
transparency is to read all the id's that match and bring them to my workstation
and then read the whole salary history table and bring that data to my 
workstation and then do the join.  Hope I do not run out of memory, disk, or 
whatever!  This could (and will) take a long time to execute.  Now with a
global query optimizer, it should be able to determine where is the best system
to the work (probably not the workstation).  Maybe it should pass the ids to 
the system containing salary history, do the join there and then pass back the 
result table to my workstation.  If most of the ids are one system, maybe it 
would be better to ship the salary history table to that system along with the
data for the ids in the other table and do the work there, still just shipping
the result table to my workstation.

Obviously as the query touches more distributed data, the problem only gets
worse.

Therefore, although having location transparency is a nice feature, it's 
usefulness for production systems is quite useless without some type of global
query optimizer.
 
Ingres stated that they have a global query optimizer, but I have not had the 
time to figure out what that really means.  Hopefully one of you bright folks
out there working with Ingres can report to us just what there global query
optimizer can do.

chuck

    Ingres's (v 6.3) 2-phase commit is fairly elegant.  Though our
    ULTRIX/SQL is only v 6.2 of Ingres, there should be some mention
    of the internals in SMURF::ULTRIX_SQL.
    
    Elaine

    'Way back in September I attended an Ingres seminar.
    
    Michael Stonebraker made the following claims about Ingres V6.3 and 
    Ingres/Star:
    
    Ingres/Star provides location transparency (Actually, he said that 
    Ingres has provided location transparency since V5).  The Star catalog
    is used to define global schemas -- how to access data from
    heterogeneous sources.  This catalog provides the transparency.
    Star now allows you to transparently access DB2, SQL/DS, IMS, VSAM, 
    Rdb, and RMS.  (all read/write except for IMS)
    
    Ingres/Star has a distributed optimizer.  I don't know how good the 
    optimizer is, but Mike indicated that it tries to limit the amount 
    of data transfered across the network.
    
    Ingres supports distributed transactions, using 2PC to maintain the 
    integrity of multiple Ingres databases.  2PC does not apply to
    non-Ingres databases.  They address an extra problem that DECdtm 
    doesn't address -- the case of the failed coordinator.  Using DECdtm,
    if the coordinator fails, the transaction sits in limbo until the 
    coordinator comes back to life and rolls back the transaction.  Using
    Ingres 2PC, if the coordinator fails, the other participants elect a 
    new coordinator which rolls back or completes the transaction.
    
    Ingres/Star supports schema change transparency.  When you update the 
    Star catalog at one location, the change is immediately reflected at
    all other locations.

    Currently, Star is ported only to VMS.  However, our local Ingres
    sales rep says the RISC/ULTRIX port is "scheduled" for 1991.
    Combined with ULTRIX/SQL, that should give us an edge in the
    U*IX environments.
    
    Elaine