> Adriano dos Santos Fernandes wrote:
> > Your "Mega-database manager" is not good than Vlad approach IMO.
> >
> Your opinion is always valued. Sometime, however, facts count, too.

The same is about yours opinion (and mine too ;))

> > It will create another "database-engine" in the provider, with
> > optimizer, parser, executor, etc, etc...
> >
> 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?

Why not improve existing optimizer ? Just add cost of roundtrip and
cost of data transfer. This cost will be zero for local tables

> > 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.

This is too optimistic for current optimizer

> 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.

How your network optimizer will join data from different data sources ?
After retrieval this data became local and they can be joined via nested
loops, merge join (requires sorting) or (when it will be implemented) via
hash join. Is not this job requires usual optimizer and other engine parts ?

Regards,
Vlad