[
https://issues.apache.org/jira/browse/CALCITE-2764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16734803#comment-16734803
]
Vladimir Sitnikov commented on CALCITE-2764:
--------------------------------------------
{quote}Multi-collated VALUES is probably 0, 1, or 2 rows. It's not worth
optimizing.{quote}
I agree that multi-collated values are not worth optimizing, however I think
multi-collated relations might appear in practice.
So we either support those or we should just take a step back and avoid use
composite for collation. Do you think it is the way to go?
Frankly speaking, composite.satisfies(composite) has perfect sense if
"composite collation" represents ("relation is sorted by (X) and also sorted by
(Y, Z)"). In other words, "sorted by (X) and also sorted by (Y, Z)" perfectly
satisfies if the requirement is "sorted by (X) and also sorted by (Y)".
"sorted by (X) and also sorted by (Y, Z)" satisfies if the requirement is
"sorted by (X) and also sorted by (Y, Z)".
In other words, the change I propose for {{composite.satisfies(composite)}}
follows the principle of the least astonishment. At least for collations.
On the other hand, current {{RelTraitSet#simplify}} just erases composites, and
it just hides sortedness from the consumer operations.
> 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)
