Currently, Calcite uses Project operator and all kinds of
ProjectXXXTranposeRule to prune unused columns. Every operator's output columns
use index to reference child operators' columns. If there is a Project operator
with child operator of a Filter, if we push project down under Filter, we will
Hi,
I've ran into RuleMatchImportanceComparator issue (see
https://issues.apache.org/jira/browse/CALCITE-2356 )
As a fun experiment, I've replaced the comparator with
Random#nextBoolean(), and it identified a bug:
https://github.com/apache/calcite/pull/1747/checks?check_run_id=384628081#step:5:78
The Apache Jenkins build system has built Calcite-Master (build #1560)
Status: Failure
Check console output at https://builds.apache.org/job/Calcite-Master/1560/ to
view the results.
Vladimir Sitnikov created CALCITE-3725:
--
Summary: RelMetadataTest fails with NPE due to unsafe
RelMetadataQuery.instance call
Key: CALCITE-3725
URL: https://issues.apache.org/jira/browse/CALCITE-3725
The Apache Jenkins build system has built Calcite-Master (build #1561)
Status: Still Failing
Check console output at https://builds.apache.org/job/Calcite-Master/1561/ to
view the results.
I could see how this would be helpful. I'm not sure I see how the property
for passing tests with different plans would work. Why not just have
randomization disabled by default? In production, predictability is
probably preferable anyway.
On Sat, Jan 11, 2020, 04:19 Vladimir Sitnikov
wrote:
> H
Michael>I'm not sure I see how the property
Michael>for passing tests with different plans would work
E.g. @Tag("skipWhenRandomizedRules") and CalciteAssert#explainContains
could become a no-op when a special property is passed.
Of course, the randomization should be for test purposes, not for
pr
Ritesh created CALCITE-3726:
---
Summary: Allow declaring type objects
Key: CALCITE-3726
URL: https://issues.apache.org/jira/browse/CALCITE-3726
Project: Calcite
Issue Type: New Feature
Re
