Re: First Impressions on Using Alphora's Dataphor

Peter,

> > The equal operator in Dataphor is "=" (assignment is ":="). Yes,
> > hashing is an excellent duplicate removal mechanism, but thus far
> > Dataphor only uses BTrees (and therefore requires ordering).
>
> Okay. This then is one of the places where the model is influenced by the
> implementation, which is quite unlucky imho.

I agree. It is on our list of things to address. We haven't found it to significantly enough affect the overall usability or usefulness of the product to bump the other tasks on our list.

> With respect to your comment on BTrees, i believed Alphora to be implemented
> on top of SQL... therefore i do not understand your explanation. Could you
> elaborate?

I would be happy to. The Dataphor compiler starts with the assumption that none of a query's operations can be handled by the storage device(s), except base table "retrieval" operations, which storage devices are required to support. The compiler creates an initial execution plan based on this assumption. The execution plan is later bound to the various storage devices at which time Dataphor determines the extent to which each device can support the query. When performing the initial compilation, the Dataphor server attempts to resolve comparison operators for duplicate elimination via the BTree that it assumes will be used. The reason this only comes up in certain places--such as sorting and duplicate removal--is due to Dataphor's pipelined query processor. In other words, Dataphor does not materialize a result set at every operator, and in most cases avoids materializing the complete set altogether.

There you have it, our laundry hanging there for all to see. :-)

Regards,

--
Nathan Allan
Alphora