My understanding is that isMap() is set to true when the cardinality of the input may not be equal to the the cardinality of the output. To settle this issue, I come up with one explicit property in my Limit Push down branch. The attribute is called canDecreaseCardinality.
On Sun, Sep 3, 2017 at 19:46 abdullah alamoudi <[email protected]> wrote: > Dear devs, > I was going over implementations of ILogicalOperator.isMap in our code > base and here is the breakdown: > > isMap() > > true: > -Assign > -AbstractReplicateOperator > -AbstractUnnestOperator > -ExchangeOperator > -InsertDeleteUpsertOperator > -LimitOperator > -ProjectOperator > -SelectOperator > > > > false: > -Order > -Aggregate > -RunningAggregate > -AbstractBinaryJoin > -AbstractOperatorWithNestedPlans > -DataSourceScanOperator > -DistinctOperator > -DistributeResultOperator > -EmptyTupleSourceOperator > -IndexInsertDeleteUpsertOperator > -IntersectOperator > -MaterializeOperator > -NestedTupleSourceOperator > -ScriptOperator > -SinkOperator > -TokenizeOperator > -UnionAllOperator > -WriteOperator > -WriteResultOperator > > As I understood at some point is that isMap means (does this operator map > input tuples to output tuples without blocking?). I am not sure how > accurate this description is but it clearly introduces a problem as: > > * InsertDeleteUpsertOperator.isMap() -> true > * IndexInsertDeleteUpsertOperator.isMap() -> false > > Moreover, > TokenizeOperator.isMap() -> false > AbstractUnnestOperator.isMap() -> true > > while clearly, as per the definition above, these two operators should > have the same output: true > > Can someone solve the mystery? > Once this is solved, I will add a wiki entry to explain this flag. > > Cheers, > Abdullah.
