calcite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maryann Xue <maryann....@gmail.com>
Subject Phoenix - Calcite integration
Date Mon, 16 Mar 2015 22:21:03 GMT
Hi Julian,

After fixing the compilation error, I ran into some runtime problems with
CalciteTest, basically all caused by attempt to cast an EmptyCompositeTrait
object to RelMultipleTrait while applying rules (either ProjectRemoveRule
or PhoenixFilterRule). Guess we missed some handling of traits in our rule
implementation. Could you please help me look at the issue? I have attached
the diff file against Phoenix calcite branch.

We got our first join query to run last week (based on calcite 1.0.0), but
I have a few questions regarding the implementation:
1. Added PhoenixJoinRule, but noticed that PhoenixSortRule did something
different with the traits than other rules. What is that for? Should I also
add something special for traits in PhoenixJoinRule? And generally I would
like to know more about traits. Like what kind of traits do we usually
have? And how are we supposed to implement a trait that indicates the
ordering of an input (like for table scan, the result comes out ordered by
primary key)?
2. splitJoinCondition() only regards lhs.column1 == rhs.column2 as equi
conditions. Is there any other class/method available to recognize equi
conditions of (any LHS expression/function) == (any RHS
expression/function), for example "lhs.column1 + 3 = rhs.column2"? Or I
write my own class?
3. Also added PhoenixProjectScanMergeRule, which pushes project into a
PhoenixTableScan. Fixed an error caused by mismatch of rowtype by simply
replacing the new PhoenixTableScan's rowtype with that of the original
PhoenixProject. Does that look ok?




Thanks,
Maryann

Mime
  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message