Re: tough choices

From: Noons <wizofoz2k_at_yahoo.com.au.nospam>
Date: Thu, 24 Jun 2004 21:56:16 +1000
Message-ID: <40dac15a$0$16104$afc38c87@news.optusnet.com.au>

Serge Rielau apparently said,on my timestamp of 24/06/2004 4:00 AM:

> Essentially what you see is a partitioned table. It just has different
> lingo attached to it. But for all the optimizer cares it is.
> This makes the difference between a partitioned table and a partitioned
> view the administration which's importance differs from case to case.

Ah OK. Very much like the union-partitions in Oracle V7. With updates thrown in. That is cool.

>> Again: so how do you optimize a UNION ALL across federated databases?

>
> sing information constarints/where predicates it is easy to do branch
> elimination with a therem prover or at least prove the partitioning
> property. The result is that only relevant remote tables will be queried
> which, in a federated environment, is a big deal.

You bet. Does the optimizer do that? I mean, I'm in node A, my data lives in node B, what does it do with my query? Ship it to node B for execution there, or get data from node B into A then run it, or a mix of the above? What if my query needs data from both A and B? Is it both indexes and data or just indexes that get branch-eliminated?

All these are relatively well handled by Oracle in partitions with SMP, as well as partitions with RAC. There are also a heap of alternatives on how to distribute the load across CPUs in both SMP and RAC. I'm just curious how UDB would handle its federated situations.

-- 
Cheers
Nuno Souto
wizofoz2k_at_yahoo.com.au.nospam

Received on Thu Jun 24 2004 - 06:56:16 CDT