Adriano dos Santos Fernandes wrote:

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

Ah, a divine revelation? A statement of faith? An epiphany?

Adriano, in technical discussion it is more often persuasive to reason
than conclusions. I know you are convinced you are right, but that is
not the issue. You must convince *us* that you are right.

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

Indeed it could. But putting it inside the engine raises more problems
that it solves. For example, there is the system table / object name
problem. And the optimizer problem. The question, however, is not
whether it could be done, but whether it is better to do it than the
known alternatives.

Vlad's proposal did not address any of these issues. Perhaps we should
allow him the time to ponder the issues and come up with suitable solutions.

"Faith based" technology, I fear, is even worse that "faith based"
politics that have lead to misery the world over. Reason is a good and
reliable tool. Let's use it.

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

I don't think that there is any disagreement that Vlad's proposal could
be hacked in to handle "just one external table". But could it be
extended to muliple tables? Tables with conflicting object names?
Could it reasonable optimize network queries? Could it support the
tools already in place?

These are the important questions. They need solutions.

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

What about the ODBC/JDBC system result sets that describe tables,
fields, etc.? Is your argument that they can be transparently emulated,
that the various drivers can be modified to handle different types of
metadata, or that metadata handling isn't important?

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

Do you consider that good enough? Are you prepared to write off
existing tools?

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

Please explain why. Are you arguing that ODBC and JDBC are not
important? Or just stating an opinion based on, well, nothing?