I agree. If the properties are the same for both Algebricks and VXQuery, we should definitely use these predefined identifiers. We may even see benefit in other areas. I posted a question to the hyracks dev group and will update when I get a reply.
On Fri, Mar 7, 2014 at 5:46 PM, Till Westmann <[email protected]> wrote: > 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. > >
