I think that the answer is "it depends". If our operator has the properties that are expected by the rule, I think that we can/should re-use the Algebricks identifier for the operator and the Algebricks rules. However, we should also document what the exact properties of an operator are, such that it fits Algebricks' expectations.
Cheers, Till On Mar 7, 2014, at 3:39 PM, Eldon Carman <[email protected]> wrote: > The join operator has opportunity to be improved. First it can use hash > based join instead of inner loop join. Also parts of the condition for the > join operation are only dependent on one side of the join. > > VXQuery does not benefit from the AlgebricksBuiltinFunctions, since each > function is created with a VXQuery namespace. The key builtin function for > the join optimization is AND. Some rewrite rules in Algebricks use these > builtin functions to modify the query plans. VXQuery does not benefit from > these rewrite rule changes since VXQuery AND is different than the > Algebricks AND. > > Is this a problem we fix by updating our definition of the AND function > definition? Or do we need to make new rewrite rules for our system? > > Thanks for your feedback > Preston > > > Algebricks has the following builtin function identifiers: EQ, LE, GE, LT, > GT, NEQ, AND, OR, NOT, ADD_NUMERIC, IS_NULL. > > Side note: AsterixDB system chooses to use these builtin function > identifiers instead of defining there own. The system still implements the > runtime, but does not define the identifier.
