[jira] [Comment Edited] (CALCITE-2764) RelCompositeTrait#satisfies does not work for non-trivial traits

["Vladimir Sitnikov (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CALCITE-2764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16734401#comment-16734401 ] 

Vladimir Sitnikov edited comment on CALCITE-2764 at 1/4/19 6:15 PM:
--------------------------------------------------------------------

{quote}Your example is clever but it is a bit contrived{quote}

Thanks, it took me a while to generate :)
It turns out multi-collated VALUES might easily appear in practice.

{quote}When implementing your query, we could not require that there is a scan of emps that is sorted on both empid and deptno{quote}
We could. The one with both collations would cost less. In other words, CalcRelSplitter could generate multiple variations of LogicalWindow relations. One that requires both collations, and the second one as a fallback just in case two-collated relation is not available.

{quote}it would be almost useless in practice.{quote}
As I said, it suits very well for CALCITE-2593.
Here's how it works: we disable RelTraitSet#simplfy. Note: currently the only thing it does it replaces composite traits (e.g. multicollations) to default (EMPTY collation). If we disable the simplification, then we'll have composite traits for RelSubsets. Then RelSubsets#getRels would use composite.satisfies(composite) case to get the list of relations matching RelSubset.


was (Author: vladimirsitnikov):
{quote}Your example is clever but it is a bit contrived{quote}

Thanks, it took me a bit to generate :)
It turns out multi-collated VALUES might easily appear in practice.

{quote}When implementing your query, we could not require that there is a scan of emps that is sorted on both empid and deptno{quote}
We could. The one with both collations would cost less. In other words, CalcRelSplitter could generate multiple variations of LogicalWindow relations. One that requires both collations, and the second one as a fallback just in case two-collated relation is not available.

{quote}it would be almost useless in practice.{quote}
As I said, it suits very well for CALCITE-2593.
Here's how it works: we disable RelTraitSet#simplfy. Note: currently the only thing it does it replaces composite traits (e.g. multicollations) to default (EMPTY collation). If we disable the simplification, then we'll have composite traits for RelSubsets. Then RelSubsets#getRels would use composite.satisfies(composite) case to get the list of relations matching RelSubset.

> RelCompositeTrait#satisfies does not work for non-trivial traits
> ----------------------------------------------------------------
>
>                 Key: CALCITE-2764
>                 URL: https://issues.apache.org/jira/browse/CALCITE-2764
>             Project: Calcite
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.18.0
>            Reporter: Vladimir Sitnikov
>            Assignee: Vladimir Sitnikov
>            Priority: Major
>             Fix For: 1.19.0
>
>
> {noformat}java.lang.AssertionError: [[0, 1], [1]].satisfies([[0, 1], [1]])
> 	at org.junit.Assert.fail(Assert.java:88)
> 	at org.junit.Assert.assertTrue(Assert.java:41)
> 	at org.apache.calcite.plan.RelTraitTest.assertSatisfies(RelTraitTest.java:81)
> 	at org.apache.calcite.plan.RelTraitTest.compositeSatisfies(RelTraitTest.java:77)
> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> 	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> 	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> 	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> 	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> 	at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> 	at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> 	at com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> 	at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> 	at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70){noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)