小黑一点都不黑 created CALCITE-3575:
Summary: JOIN 条件下推引入BUG
Key: CALCITE-3575
URL: https://issues.apache.org/jira/browse/CALCITE-3575
Project: Calcite
Issue Type: Bug
Components: core
Aitozi created CALCITE-3574:
---
Summary: Add rlike syntax
Key: CALCITE-3574
URL: https://issues.apache.org/jira/browse/CALCITE-3574
Project: Calcite
Issue Type: Improvement
Components:
I was attempting to make Avatica 1.16.0-rc0 available for voting, but
ran into a few show stopper bugs.
Vladimir would probably be the best person to fix this as he did most of
the migration to Gralde.
A few things I noticed:
- I am using -Pasf.git.pushRepositoryProvider=GITBOX to push the
Francis Chuang created CALCITE-3573:
---
Summary: Upgrade to Gradle 6.0 container to build releases and
javadoc
Key: CALCITE-3573
URL: https://issues.apache.org/jira/browse/CALCITE-3573
Project:
Oh, I forgot to mention that the join planning/reordering is not a big problem.
Calcite just use the rule to generate a single alternative plan, which is not
ideal. But we can't say Calcite is doing wrong.
Ideally, we expect it generates multiple (neither all, nor single) bipartie
graphs. The
xzh_dz created CALCITE-3572:
---
Summary: Lack of Hints information when serialization and
deserialization
Key: CALCITE-3572
URL: https://issues.apache.org/jira/browse/CALCITE-3572
Project: Calcite
Generally agree with what Vladimir said. I think what Calcite has is logical
optimization or exploration, there are almost no physical optimization, Calcite
leaves it to third party implementators. One of my friends at University of
Wisconsin–Madison database research group told me that they
Kirill Kozlov created CALCITE-3571:
--
Summary: RelBuilder#shouldMergeProject throws an exception for
JOIN with complex conditions
Key: CALCITE-3571
URL: https://issues.apache.org/jira/browse/CALCITE-3571
Pls see CALCITE-3560 [1] which was merged recently. You can now instantiate
Source from a generic CharSource [2]:
Source source = Sources.fromCharSource(CharSource.wrap("hello"));
This should be released with 1.22
[1] https://issues.apache.org/jira/browse/CALCITE-3560
AbstractConverter-s are attractive because they effectively emulate
straightforward recursive top-down optimization (Volcano/Cascades). But
instead of doing it with a recursive method call, which preserves the
context, we do this in Calcite as a sequence of unrelated rule calls, thus
losing the
Vladimir,
thank you for bringing it up. We are facing the same problems in Apache
Ignite project
and it would be great if Apache Calcite community will propose a
solution for this
issue.
From my point of view an approach with abstract converters looks more
promising, but as
you mentioned it
Hi,
As I mentioned before, we are building a distributed SQL engine that uses
Apache Calcite for query optimization. The key problem we faced is the
inability to pull the physical traits of child relations efficiently. I'd
like to outline my understanding of the problem (I guess it was already
Michael> -0 because I haven't found checkstyle violations
Michael> and I don't like the idea of losing checks which are currently in
Michael> place
Would you please re-evaluate? I seems like you did not know which checks
are there and which are not.
To my best knowledge, the only missing check
13 matches
Mail list logo
