Re: tough choices

You cannot compare federated with RAC or SMP. Federated databses are not federated because it's nice or because it's preferred technology.
They are federated is by necessity.
If you take a look at health care, a lot of the data cannot be replicated to a central store for leagal reason. It may or may not be OK to query the data directly (store it in the DBMS's cache) but copying the the data to be stored persistently is a no-no. So federation is all about coping with an imperfect world (from the DBMS' point of view).

DB2 II can indeed push parts of the (optimized) query to the remote side. It works not all that different from the shared nothing algorithms. The difference is that instead of shipping "DB2 byte code" to the database partition to be executed. DB2 II reverse engineers the remote DBMS' SQL dialect and uses the remotes native client interfaces to pose the query.
Doing a join between a Oracle and SQL Server can mean: a) Pull the data to DB2 II , then join locally b) Pull the data from SQL Server to DB2 II, push it to Oracle and join on Oracle
c) Reverse from b)

To do this the DBMS has to know a fair bit about the remote DBMS capabilities.
E.g. if DB2 II based it's decision on a hash-join costing but the remote doesn't know what that is things go sour.

In a life sciences space there often isn't even any choice. The remote side (which may not be relational to start with) may have certain functions (like detetcing a gene-sequence match) which DB2 II does not have and which can-not or must not (IP) implemented in DB2. In this case a fucntion mapping is provided to model teh foreing function and DB2 II knows that any plan must involve pushing the foreign function to it's native source.

The remise in this case is that the user does not need to worry about learning the remote's interfaces or mix query languages.

Cheers
Serge

-- 
Serge Rielau
DB2 SQL Compiler Development
IBM Toronto Lab