Re: A question for Mr. Celko

Paul <paul_at_test.com> wrote in message news:<40fef0dd$0$96012$ed2619ec_at_ptn-nntp-reader03.plus.net>...
> The way I see it, to the relational engine, all values are just black
> boxes. When it needs to perform some non-relational operation on some
> values it just passes the problem on to the type engine.

Okay, I think I understand your point now, and I see why you used the terminology type engine (note that I equated it to type system in my previous post, I was incorrect in this). The way I see it, indeed the way our engine is implemented, the relational engine and the type engine are one and the same. Operators take arguments and return values. The type of those values is independent of the operation being performed. Similarly, our optimizer considers all operations as peers, so I don't see a separation here.

> Now in the special case where the type itself is "relations", the type
> engine has its own little RDBMS that it uses to perform relational
> operations within the context of the type. But this RDBMS is logically
> totally separate to the orginal external RDBMS. i.e you shouldn't be
> able to join a relation-value with a "real" relation in your main RDBMS:
> the only communication between the two should be via the type engine.

I see why the architecture you are describing would prescribe this, but I don't see why the problem necessitates this architecture. The problem of optimization is the same regardless of the types of values involved: reorganize the execution tree to obtain a more efficient implementation, whether that involves constant folding, expression transformation, or access path determination, the problem is the same.

Regards,
Bryn Received on Thu Jul 22 2004 - 05:54:29 CEST