> For instance, it thinks Join(A, B, $0=$1) and Join(A, B, $1=$0) are different
> joins, however, they are equivalent.
How is the alternative generated? I would rather check how to stop generating
this alternative than reordering predicates.
- Haisheng
Danny>How much cases are there in production ? This example itself seems
very marginalized. I’m not against with it, I’m suspicious about the value
of the feature.
It improves JdbcTest#testJoinManyWay 2 times or so.
master.
JdbcTest#testJoinManyWay: 5.8sec
Hi, community
I was investigating lattice recently and encountered some problems:
1. Lattice requires the estimated number of rows of cuboids (tiles) for
optimization. I've found the method: `TileSuggester.StatisticsProviderImpl
# getRowCount`, `LatticeStatisticProvider # cardinality`, but I
Danny Chen created CALCITE-3649:
---
Summary: Hints should be propagated correctly in planner rules if
original node is transformed to different kind
Key: CALCITE-3649
URL:
Ritesh created CALCITE-3648:
---
Summary: MySQL DECOMPRESS function support
Key: CALCITE-3648
URL: https://issues.apache.org/jira/browse/CALCITE-3648
Project: Calcite
Issue Type: Sub-task
Ritesh created CALCITE-3647:
---
Summary: MySQL COMPRESS function support
Key: CALCITE-3647
URL: https://issues.apache.org/jira/browse/CALCITE-3647
Project: Calcite
Issue Type: Sub-task
Ritesh created CALCITE-3646:
---
Summary: MySQL compression functions
Key: CALCITE-3646
URL: https://issues.apache.org/jira/browse/CALCITE-3646
Project: Calcite
Issue Type: New Feature
xzh_dz created CALCITE-3645:
---
Summary: Add columnMappings in digest and explainTerms methods.
Key: CALCITE-3645
URL: https://issues.apache.org/jira/browse/CALCITE-3645
Project: Calcite
Issue Type:
> We do not normalize RexNodes, thus it results in excessive planning time,
> especially when the planner is trying to reorder joins.
> For instance, it thinks Join(A, B, $0=$1) and Join(A, B, $1=$0) are
> different joins, however, they are equivalent.
How much cases are there in production ?
xzh_dz created CALCITE-3644:
---
Summary: Calc on the Intersecrt in target is not being matched
Key: CALCITE-3644
URL: https://issues.apache.org/jira/browse/CALCITE-3644
Project: Calcite
Issue Type:
>> =(CAST(PREV(UP.$0, 0)):INTEGER NOT NULL, 100)
I don't see the value of reordering this kind of expression. In GPDB, var vs
constant comparison is reordered for input ref only, without additional
function calls, like $1=5, because it is transformed into range constraints for
rex
Just in case, my motivation of comparing by string length first is for the
cases like below:
=(CAST(PREV(UP.$0, 0)):INTEGER NOT NULL, 100)
vs
=(100, CAST(PREV(UP.$0, 0)):INTEGER NOT NULL)
As for me, the second one is easier to understand, do the expression starts
with simpler bits, and
the
Haisheng> variable always left, constant always right for applicable binary
operators;
Oh, I did not think of making different behavior for literals, variables.
What do you think re "$n.field = 42" where $n.field is a dot operator
I'm not fond of adding complicated checks there, however, I think
It turned out "b" (sort operands in computeDigest) is easier to implement.
I've filed a PR: https://github.com/apache/calcite/pull/1703
>($0, 2) vs <(2, $0) might be less trivial to implement, but I think it is
worth doing at the same time.
In any case, lots of expressions will need to be
I recommend the way GPDB does.
Normalize the the logical plan expression in the preprocessing phase:
- variable always left, constant always right for applicable binary operators;
- for join conditions, left operand always comes from left relation, right
operand always comes from right relation
Il dom 29 dic 2019, 20:09 Vladimir Sitnikov
ha scritto:
> Hi,
>
> We have a 1-year old issue with an idea to sort RexNode operands so they
> are consistent.
>
> For instance, "x=5" and "5=x" have the same semantics, so it would make
> sense to stick to a single implementation.
> A discussion can
Hi,
We have a 1-year old issue with an idea to sort RexNode operands so they
are consistent.
For instance, "x=5" and "5=x" have the same semantics, so it would make
sense to stick to a single implementation.
A discussion can be found in
https://issues.apache.org/jira/browse/CALCITE-2450
We do
Hi,
I'm inclined to revert
https://github.com/apache/calcite/commit/48a20668647b5a5e86073ef0e9ce206669ad6867
Motivation can be found in
https://issues.apache.org/jira/browse/CALCITE-1842?focusedCommentId=17004696=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17004696
Stamitis>I was thinking that if the check says that there is no problem
then apply
would be a noop.
The current logic of 'apply' is it computes the appropriate style and
overwrites the file.
Do you suggest it to skip overwriting in case the only diff is line endings?
What if there are other
I was thinking that if the check says that there is no problem then apply
would be a noop.
I have the impression that source releases are necessary and obligatory so
that the ASF is covered from a legal perspective. If I am not mistaken even
companies with closed source code are obliged to
It turned out to be more complicated than I thought.
The fix of EnumerableMergeJoin uncovered a well-known infinite planning
time issue https://issues.apache.org/jira/browse/CALCITE-2223
The thing is previously the rule did not even try to sort its inputs, thus
it was producing value only for
The Apache Jenkins build system has built Calcite-Master (build #1525)
Status: Still Failing
Check console output at https://builds.apache.org/job/Calcite-Master/1525/ to
view the results.
Vladimir Sitnikov created CALCITE-3643:
--
Summary: Prevent matching JoinCommuteRule when both inputs are the
same
Key: CALCITE-3643
URL: https://issues.apache.org/jira/browse/CALCITE-3643
The Apache Jenkins build system has built Calcite-Master (build #1524)
Status: Failure
Check console output at https://builds.apache.org/job/Calcite-Master/1524/ to
view the results.
24 matches
Mail list logo
