Jim Starkey escreveu:

> Yes? And since the process to optimize network queries is quite
> different from local queries, isn't this necessary and even desirable?
> Nothing says that suitable code from the Firebird engine can't be
> reused, but since the existing optimizer and runtime don't quite do what
> is necessary to manage network queries, doesn't it make sense to build a
> specialized engine?
>

No.

>> It will not allow to optimize joins (and whatever) of different
>> databases in the same engine.
>>
>>
> That's a strange and interesting assertion. On what is it based?
>
> The basic idea of network optimization is to decompose a complex query
> into a set of independent queries to execute at each network node
> involved in the query. For efficiency, each of these queries should be
> designed to give the remote engine(s) the best possible opportunity for
> local optimization.
>
> The Firebird optimizer is essentially cost based. A network optimizer
> is generally heuristic based, concerning itself less with the cost of
> fetch records from disk than minimizing round trips and the volume of
> data transmitted.
>

This "gateway" could also be inside the engine.

It's much more user friendly to just declare a "db-link" and use it than
create another database, in a provider that will be almost untested (too
much people lived without cross db queries and will continue living).

Think about a production environment, accessing just one external table
when necessity arrives...

> Perhaps you missed the discussion of metadata and tools. You may want
> to review it before deciding the metadata isn't important.

The engine can pass metadata describe commands (via info api) to
external providers.

For example, Oracle engine doesn't support the command DESC (our ISQL
SHOW TABLE, for who doesn't know), but I can "desc x@z" in SQL*Plus and
it shows the metadata.

I don't thing we need to store or retrieve external metadata from our
system tables.


Adriano