[jira] [Closed] (CALCITE-4955) Release Calcite 1.29.0
[ https://issues.apache.org/jira/browse/CALCITE-4955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rui Wang closed CALCITE-4955. - Resolution: Fixed > Release Calcite 1.29.0 > -- > > Key: CALCITE-4955 > URL: https://issues.apache.org/jira/browse/CALCITE-4955 > Project: Calcite > Issue Type: Task >Reporter: Rui Wang >Assignee: Rui Wang >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (CALCITE-4704) Log produced plan after rule application using explain formatting
[
https://issues.apache.org/jira/browse/CALCITE-4704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rui Wang closed CALCITE-4704.
-
> Log produced plan after rule application using explain formatting
> -
>
> Key: CALCITE-4704
> URL: https://issues.apache.org/jira/browse/CALCITE-4704
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.27.0
>Reporter: Stamatis Zampetakis
>Assignee: Stamatis Zampetakis
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.29.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> In many cases, we want to identify which rule lead to a certain
> transformation in the plan or need to observe how the query plan evolves by
> applying some rules in order to fix some bug or find the right place to
> introduce another optimization step.
> Currently there are some logs during the application of a rule triggered by
> the
> [HepPlanner|https://github.com/apache/calcite/blob/e04f3b08dcfb6910ff4df3810772c346b25ed424/core/src/main/java/org/apache/calcite/plan/AbstractRelOptPlanner.java#L367]
> and
> [VolcanoPlanner|https://github.com/apache/calcite/blob/e04f3b08dcfb6910ff4df3810772c346b25ed424/core/src/main/java/org/apache/calcite/plan/volcano/VolcanoRuleCall.java#L126]
> but they more or less display only the top operator of the transformation
> and not the whole subtree. Moreover, the {{RelNode#toString}} used in these
> logs, is not self-contained, so in order to check the transformation the log
> entry needs to be matched with other logs.
> It would help if instead of displaying only the top operator we logged the
> equivalent of explain (i.e., {{RelOptUtil.toString}}) on the transformed
> sub-tree.
> You can find below some extracts from the current logs and how the proposed
> log could look like.
> *HepPlanner*
> +Current logging+
> {noformat}
> 2021-07-27 14:37:58,252 [ForkJoinPool-1-worker-9] DEBUG - call#0: Rule
> FilterIntoJoinRule arguments
> [rel#9:LogicalFilter.NONE.[](input=HepRelVertex#8,condition==($7, $8)),
> rel#7:LogicalJoin.NONE.[](left=HepRelVertex#5,right=HepRelVertex#6,condition=true,joinType=left)]
> produced
> rel#14:LogicalProject.NONE.[](input=LogicalJoin#13,inputs=0..7,exprs=[CAST($8):TINYINT,
> $9, $10])
> 2021-07-27 14:37:58,266 [ForkJoinPool-1-worker-9] DEBUG - call#1: Rule
> ProjectJoinTransposeRule arguments
> [rel#16:LogicalProject.NONE.[](input=HepRelVertex#15,inputs=0..7,exprs=[CAST($8):TINYINT,
> $9, $10]),
> rel#13:LogicalJoin.NONE.[](left=HepRelVertex#5,right=HepRelVertex#6,condition==($7,
> $8),joinType=inner)] produced
> rel#21:LogicalProject.NONE.[](input=LogicalJoin#20,inputs=0..7,exprs=[$11,
> $9, $10])
> 2021-07-27 14:37:58,269 [ForkJoinPool-1-worker-9] DEBUG - call#3: Rule
> ProjectMergeRule arguments
> [rel#11:LogicalProject.NONE.[](input=HepRelVertex#27,exprs=[$1]),
> rel#26:LogicalProject.NONE.[](input=HepRelVertex#25,inputs=0..7,exprs=[$11,
> $9, $10])] produced
> rel#28:LogicalProject.NONE.[](input=HepRelVertex#25,exprs=[$1])
> 2021-07-27 14:37:58,272 [ForkJoinPool-1-worker-9] DEBUG - call#4: Rule
> ProjectJoinTransposeRule arguments
> [rel#28:LogicalProject.NONE.[](input=HepRelVertex#25,exprs=[$1]),
> rel#24:LogicalJoin.NONE.[](left=HepRelVertex#22,right=HepRelVertex#23,condition==($7,
> $8),joinType=inner)] produced
> rel#33:LogicalProject.NONE.[](input=LogicalJoin#32,inputs=0)
> 2021-07-27 14:37:58,274 [ForkJoinPool-1-worker-9] DEBUG - call#6: Rule
> ProjectMergeRule arguments
> [rel#30:LogicalProject.NONE.[](input=HepRelVertex#22,exprs=[$1, $7]),
> rel#18:LogicalProject.NONE.[0](input=HepRelVertex#5,inputs=0..7)] produced
> rel#40:LogicalProject.NONE.[](input=HepRelVertex#5,exprs=[$1, $7])
> 2021-07-27 14:37:58,275 [ForkJoinPool-1-worker-9] DEBUG - call#7: Rule
> ProjectMergeRule arguments
> [rel#31:LogicalProject.NONE.[0](input=HepRelVertex#23,inputs=0),
> rel#19:LogicalProject.NONE.[[0],
> [3]](input=HepRelVertex#6,inputs=0..2,exprs=[CAST($0):TINYINT])] produced
> rel#42:LogicalProject.NONE.[0](input=HepRelVertex#6,inputs=0)
> {noformat}
> +Proposed logging+
> {noformat}
> 2021-07-27 14:37:58,260 [ForkJoinPool-1-worker-9] DEBUG - Rule
> FilterIntoJoinRule produced:
> LogicalProject(EMPNO=[$0], ENAME=[$1], JOB=[$2], MGR=[$3], HIREDATE=[$4],
> SAL=[$5], COMM=[$6], DEPTNO=[$7], DEPTNO0=[CAST($8):TINYINT], DNAME=[$9],
> LOC=[$10])
> LogicalJoin(condition=[=($7, $8)], joinType=[inner])
> LogicalTableScan(table=[[scott, EMP]])
> LogicalTableScan(table=[[scott, DEPT]])
> 2021-07-27 14:37:58,267 [ForkJoinPool-1-worker-9] DEBUG - Rule
> ProjectJoinTransposeRule produced:
> LogicalProject(EMPNO=[$0], ENAME=[$1], JOB=[$2], MGR=[$3], HIREDATE=[$4],
> SAL=[$5], COMM=[$6], DEPTNO=[$7],
[jira] [Closed] (CALCITE-4700) AggregateUnionTransposeRule produces wrong group sets for the top Aggregate
[
https://issues.apache.org/jira/browse/CALCITE-4700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rui Wang closed CALCITE-4700.
-
> AggregateUnionTransposeRule produces wrong group sets for the top Aggregate
> ---
>
> Key: CALCITE-4700
> URL: https://issues.apache.org/jira/browse/CALCITE-4700
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.28.0
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.29.0
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Consider the following tree:
> {code}
> LogicalAggregate[groupSet=$1, ...]
> LogicalUnion
> Input
> {code}
> When the rule is applied, the top-level Aggregate receives the same group set
> as the original Aggregate, which is wrong because it points to an incorrect
> attribute.
> {code}
> LogicalAggregate[groupSet=$1, ...] // <- wrong
> LogicalUnion
> LogicalAggregate[groupSet=$1, ...]
> Input
> {code}
> The correct plan should be:
> {code}
> LogicalAggregate[groupSet=$0, ...]
> LogicalUnion
> LogicalAggregate[groupSet=$1, ...]
> Input
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (CALCITE-4131) the XmlFunctions exception handled by System.out
[
https://issues.apache.org/jira/browse/CALCITE-4131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rui Wang closed CALCITE-4131.
-
> the XmlFunctions exception handled by System.out
>
>
> Key: CALCITE-4131
> URL: https://issues.apache.org/jira/browse/CALCITE-4131
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Haisheng Yuan
>Assignee: duan xiong
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.29.0
>
> Attachments: after apply the PR.png, before apply the PR.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The error doesn't affect the proceeding of the test suite, and doesn't fail
> the test. But the error message is not so pleasing:
> {code:java}
> SqlToRelConverterExtendedTest > testCrossJoinLateral1() STANDARD_ERROR
> [Fatal Error] :1:2: XML document structures must start and end within the
> same entity.
> ERROR: 'Could not compile stylesheet'
> FATAL ERROR: 'XML document structures must start and end within the same
> entity.'
>:XML document structures must start and end within the same
> entity.
> SqlToRelConverterExtendedTest > testMatchRecognizeIn() STANDARD_ERROR
> ERROR: 'XML document structures must start and end within the same
> entity.'
> ERROR: 'com.sun.org.apache.xml.internal.utils.WrappedRuntimeException:
> XML document structures must start and end within the same entity.'
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (CALCITE-4737) Add RelOptPlanner visualizer for debugging
[ https://issues.apache.org/jira/browse/CALCITE-4737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rui Wang closed CALCITE-4737. - > Add RelOptPlanner visualizer for debugging > -- > > Key: CALCITE-4737 > URL: https://issues.apache.org/jira/browse/CALCITE-4737 > Project: Calcite > Issue Type: New Feature >Reporter: Julian Hyde >Assignee: Thomas Rebele >Priority: Major > Labels: pull-request-available > Fix For: 1.29.0 > > Time Spent: 9h 20m > Remaining Estimate: 0h > > Add Volcano visualizer for debugging. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (CALCITE-4841) Support decimal column type in CSV and File adapter
[ https://issues.apache.org/jira/browse/CALCITE-4841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rui Wang closed CALCITE-4841. - > Support decimal column type in CSV and File adapter > --- > > Key: CALCITE-4841 > URL: https://issues.apache.org/jira/browse/CALCITE-4841 > Project: Calcite > Issue Type: Improvement > Components: csv-adapter, file-adapter >Reporter: Louis Kuang >Priority: Minor > Labels: pull-request-available > Fix For: 1.29.0 > > Time Spent: 3h 20m > Remaining Estimate: 0h > > Currently, the csv adapter does not support the decimal/numeric column type > (see supported types in > [CsvFieldType|https://github.com/apache/calcite/blob/4bc916619fd286b2c0cc4d5c653c96a68801d74e/file/src/main/java/org/apache/calcite/adapter/file/CsvFieldType.java#L35]. > Any type that is not supported will be interpreted by the > [CsvEnumerator|https://github.com/apache/calcite/blob/master/file/src/main/java/org/apache/calcite/adapter/file/CsvEnumerator.java] > as string. > When dealing with decimal numbers, the currently most appropriate type is > `double`. However, this is not accurate enough for financial data. This > feature request proposes adding a `decimal` column type that will be > implemented by the Java `BigDecimal` type (and by conversion in > [JavaToSqlTypeConversionRules|https://github.com/apache/calcite/blob/4bc916619fd286b2c0cc4d5c653c96a68801d74e/core/src/main/java/org/apache/calcite/sql/type/JavaToSqlTypeConversionRules.java#L74] > be represented as a `Decimal` SQL type). This allow financial data to be > represented and computed more accurately (`BigDecimal` has higher precision > than `double`). > Please see sample implementation in PR. > Context: I am trying to leverage Calcite to add some SQL support to > [ledger|https://www.ledger-cli.org/] reporting. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (CALCITE-4822) Add ARRAY_CONCAT, ARRAY_REVERSE, ARRAY_LENGTH for BigQuery dialect
[
https://issues.apache.org/jira/browse/CALCITE-4822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rui Wang closed CALCITE-4822.
-
> Add ARRAY_CONCAT, ARRAY_REVERSE, ARRAY_LENGTH for BigQuery dialect
> --
>
> Key: CALCITE-4822
> URL: https://issues.apache.org/jira/browse/CALCITE-4822
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Sergey Nuyanzin
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.29.0
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> {{ARRAY_CONCAT}} - Concatenates one or more arrays with the same element type
> into a single array.
> {{ARRAY_LENGTH}} - Returns the size of the array. Synonym for
> {{CARDINALITY}}.
> {{ARRAY_REVERSE}} - Returns the input ARRAY with elements in reverse order.
> For more details
>
> [https://cloud.google.com/bigquery/docs/reference/standard-sql/array_functions#array_concat]
>
> [https://cloud.google.com/bigquery/docs/reference/standard-sql/array_functions#array_length]
>
> [https://cloud.google.com/bigquery/docs/reference/standard-sql/array_functions#array_reverse]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (CALCITE-4839) Remove remnants of ImmutableBeans post 1.28 release
[ https://issues.apache.org/jira/browse/CALCITE-4839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rui Wang closed CALCITE-4839. - > Remove remnants of ImmutableBeans post 1.28 release > --- > > Key: CALCITE-4839 > URL: https://issues.apache.org/jira/browse/CALCITE-4839 > Project: Calcite > Issue Type: Task >Reporter: Jacques Nadeau >Assignee: Jacques Nadeau >Priority: Major > Labels: pull-request-available > Fix For: 1.29.0 > > Time Spent: 20m > Remaining Estimate: 0h > > This is final piece of work related to moving to Immutables. Once we release, > we need to go through and remove all the shims to support deprecation. This > includes deleting ImmutableBeans and the associated tests and annotations. We > also need to remove the deprecated Config interfaces (where they have new > names). -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (CALCITE-4846) IN-list that includes NULL converted to Values throws exception
[
https://issues.apache.org/jira/browse/CALCITE-4846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rui Wang closed CALCITE-4846.
-
> IN-list that includes NULL converted to Values throws exception
> ---
>
> Key: CALCITE-4846
> URL: https://issues.apache.org/jira/browse/CALCITE-4846
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.27.0
>Reporter: duan xiong
>Assignee: duan xiong
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.29.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Run this SQL in JdbcExample :
> {code:java}
> select * from foodmart.sales_fact_1997 as s where s.cust_id not in (null,
> 100)
> {code}
> will throw an exception:
> {noformat}
> Caused by: org.apache.calcite.runtime.CalciteException: Cannot convert null
> to int{noformat}
> Because when convert ROW values generate the wrong RelDataType:
> {noformat}
> type=RecordType(JavaType(int) ROW_VALUE),tuples=[{ null }, { 100 }]){noformat}
> should be(nullable):
> {noformat}
> type=RecordType(INTEGER ROW_VALUE),tuples=[{ null }, { 100 }]){noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (CALCITE-4795) In class SqlBasicCall, make the "operands" field private
[
https://issues.apache.org/jira/browse/CALCITE-4795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rui Wang closed CALCITE-4795.
-
> In class SqlBasicCall, make the "operands" field private
>
>
> Key: CALCITE-4795
> URL: https://issues.apache.org/jira/browse/CALCITE-4795
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.29.0
>
>
> In {{class SqlBasicCall}}, the {{operands}}
> [field|https://github.com/apache/calcite/blob/4bc916619fd286b2c0cc4d5c653c96a68801d74e/core/src/main/java/org/apache/calcite/sql/SqlBasicCall.java#L34]
> is a {{public}} array. This seems crazy to me – any client might be writing
> into that field at any time. I propose to make the field private.
> This presents some compatibility problems, because people might be depending
> on the field. So I propose a quick deprecation and removal:
> * In release 1.28 (the next release, as I write this) the field and the
> {{public SqlNode[] getOperands()}} method will be marked deprecated. We will
> mirror into another field, {{private final List operandList =
> Arrays.asList(operands);}} We can replace all uses of the {{operands}} field
> in Calcite with uses of the new {{operandList}} field.
> * In release 1.29 (the release after next) the {{operands}} field and the
> {{getOperands()}} method will be removed. People can operate using
> {{List getOperandList()}} and {{setOperand(int, SqlNode)}} methods
> that are inherited from {{SqlCall}}.
> After the field is a private list, we could consider making it an immutable
> list. The list would be copied when people call {{setOperand}}, but would not
> need to be cloned when the {{SqlBasicCall}} is created or cloned.
> This case completes the work started in CALCITE-147.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (CALCITE-4768) Upgrade DataStax Driver for Apache Cassandra® version to latest 4.x
[ https://issues.apache.org/jira/browse/CALCITE-4768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rui Wang closed CALCITE-4768. - > Upgrade DataStax Driver for Apache Cassandra® version to latest 4.x > --- > > Key: CALCITE-4768 > URL: https://issues.apache.org/jira/browse/CALCITE-4768 > Project: Calcite > Issue Type: Improvement > Components: cassandra-adapter >Affects Versions: 1.27.0 >Reporter: Madhavan >Assignee: Alessandro Solimando >Priority: Critical > Labels: pull-request-available > Fix For: 1.29.0 > > Time Spent: 4h 10m > Remaining Estimate: 0h > > The Cassandra driver in Calcite uses the very old & outdated [3.6.0 > driver|https://github.com/apache/calcite/blob/calcite-1.27.0/gradle.properties#L82]. > The latest driver at the time of this writing is > [4.13.0|https://docs.datastax.com/en/developer/java-driver/4.13/changelog/#changelog], > also checkout the [upgrade guide from 3.x to > 4.x|https://docs.datastax.com/en/developer/java-driver/4.11/upgrade_guide/]. > Upgrading the driver will enable Calcite [& other projects that uses Calcite > like Drill, etc.,] users to interact with any Cassandra cluster of version > 1.x, 2.x, 3.x, 4.x or even the [DBaaS versions using Secure Connect Bundle > (SCB)|https://docs.datastax.com/en/astra/docs/connecting-to-your-database-with-the-datastax-java-driver.html] > and leverage the fixes, feature and improvements done all only in the > Unified Drivers moving forward. > Related News: > * [Introducing DataStax Java Driver > 4|https://www.datastax.com/blog/introducing-java-driver-4] > * [Better drivers for > Cassandra|https://www.datastax.com/blog/better-drivers-for-cassandra] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (CALCITE-4818) AggregateExpandDistinctAggregatesRule must infer correct data type for top aggregate calls
[
https://issues.apache.org/jira/browse/CALCITE-4818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rui Wang closed CALCITE-4818.
-
> AggregateExpandDistinctAggregatesRule must infer correct data type for top
> aggregate calls
> --
>
> Key: CALCITE-4818
> URL: https://issues.apache.org/jira/browse/CALCITE-4818
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.27.0
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.29.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> When SUM data type derivation is more complex, e.g.:
> {code}
> SUM(TINYINT | SMALLINT | INTEGER) -> BIGINT
> SUM(BIGINT) -> DECIMAL
> {code}
> The rule {{AggregateExpandDistinctAggregatesRule}} creates the top aggregate
> calls with invalid type for not distinct calls.
> e.g. {{SELECT SUM(comm), SUM(DISTINCT comm) FROM emp}}
> Please take a look at the reproducer in the PR.
> *Proposed fix:* infer type of top aggregates by input row type. Pass
> {{null}} type to the call method {{AggregateCall#create}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (CALCITE-4856) Gradle prepareVote fails with 'not authorized'
[
https://issues.apache.org/jira/browse/CALCITE-4856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rui Wang closed CALCITE-4856.
-
> Gradle prepareVote fails with 'not authorized'
> --
>
> Key: CALCITE-4856
> URL: https://issues.apache.org/jira/browse/CALCITE-4856
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Priority: Major
> Fix For: 1.29.0
>
>
> Gradle {{prepareVote}} fails with 'not authorized' error.
> {noformat}
> $ ./gradlew prepareVote -Prc=0 -Pasf
> > Configure project :
> Building Apache Calcite 1.28.0
> > Task :gitProps
> Execution optimizations have been disabled for task ':gitProps' to ensure
> correctness due to the following reasons:
> - Gradle detected a problem with the following location:
> '/home/jhyde/dev/release/calcite'. Reason: Task ':gitProps' uses this output
> of task ':babel:fmppMain' without declaring an explicit or implicit
> dependency. This can lead to incorrect results being produced, depending on
> what order the tasks are executed. Please refer to
> https://docs.gradle.org/7.2/userguide/validation_problems.html#implicit_dependency
> for more details about this problem.
> ...
> > Task :pushRcTag
> Pushing tag to Git remote release-origin:
> https://github.com/apache/calcite.git
> > Task :pushRcTag FAILED
> Build calcite FAILURE reason:
> Execution failed for task ':pushRcTag':
> Caused by: org.eclipse.jgit.api.errors.TransportException:
> https://github.com/apache/calcite.git: not authorized
> at org.eclipse.jgit.api.PushCommand.call(PushCommand.java:180)
> at
> com.github.vlsi.gradle.release.jgit.dsl.GitExtensionsKt.push(GitExtensions.kt:132)
> at
> com.github.vlsi.gradle.release.GitPushTask$pushTag$1.invoke(GitPushTask.kt:54)
> at
> com.github.vlsi.gradle.release.GitPushTask$pushTag$1.invoke(GitPushTask.kt:30)
> at
> com.github.vlsi.gradle.release.DefaultGitTask.jgit(DefaultGitTask.kt:45)
> at
> com.github.vlsi.gradle.release.GitPushTask.pushTag(GitPushTask.kt:50)
> at
> org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:104)
> at
> org.gradle.api.internal.project.taskfactory.StandardTaskAction.doExecute(StandardTaskAction.java:58)
> ...
> at
> org.eclipse.jgit.transport.Transport.push(Transport.java:1368)
> at org.eclipse.jgit.api.PushCommand.call(PushCommand.java:170)
> ... 89 more
> FAILURE: Build failed with an exception.
> * What went wrong:
> Execution failed for task ':pushRcTag'.
> > org.eclipse.jgit.api.errors.TransportException:
> > https://github.com/apache/calcite.git: not authorized
> * Try:
> Run with --stacktrace option to get the stack trace. Run with --info or
> --debug option to get more log output. Run with --scan to get full insights.
> * Get more help at https://help.gradle.org
> Deprecated Gradle features were used in this build, making it incompatible
> with Gradle 8.0.
> You can use '--warning-mode all' to show the individual deprecation warnings
> and determine if they come from your own scripts or plugins.
> See
> https://docs.gradle.org/7.2/userguide/command_line_interface.html#sec:command_line_warnings
> Execution optimizations have been disabled for 29 invalid unit(s) of work
> during this build to ensure correctness.
> Please consult deprecation warnings for more details.
> BUILD FAILED in 2m 32s
> 268 actionable tasks: 187 executed, 20 from cache, 61 up-to-date
> S3 cache 5s wasted (3s wasted on hits, 2s wasted on misses), reads: 43, hits:
> 20, elapsed: 5s, received: 8 KiB
> {noformat}
> I had tried previously without the {{-Pasf}} flag but that ran into other
> errors, sooner in the process, that seemed to be about my environment. I
> concluded that the dry-run was a waste of time.
> I'm not sure why the command is trying to push to github rather than gitbox.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (CALCITE-4844) IN-list that references columns is wrongly converted to Values, and gives incorrect results
[
https://issues.apache.org/jira/browse/CALCITE-4844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rui Wang closed CALCITE-4844.
-
> IN-list that references columns is wrongly converted to Values, and gives
> incorrect results
> ---
>
> Key: CALCITE-4844
> URL: https://issues.apache.org/jira/browse/CALCITE-4844
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.27.0
>Reporter: duan xiong
>Assignee: duan xiong
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.29.0
>
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> This problem only occurs in large IN-lists, because small IN-lists - those
> smaller than SqlToRelConverter.Config.InSubQueryThreshold - are always
> converted to OR, and converting to OR always gives correct results. For
> correct results, IN-lists that reference column values must be converted to
> OR, no matter how large they are.
> According CALCITE-1155[Support columns for IN list]. We support
> {code:java}
> 'x in (a, b, c)' {code}
> by expands to
> {code:java}
> 'x = a or x = b or x = c'{code}
> In Calcite. Only the list size smaller than the value of the sub-query
> threshold can convert. We should ignore the the value of the sub-query
> threshold to convert this.
> This issue can reproduce by add a unit test in SqlToRelConverterTest:
> {code:java}
> @Test void testInListIncludeColumns() {
> final String sql = "SELECT empno\n"
> + "FROM emp AS e\n"
> + "WHERE 130 in (empno, deptno)";
> sql(sql).withConfig(b -> b.withInSubQueryThreshold(3))
> .convertsTo(
> "\n" +
> "LogicalProject(EMPNO=[$0])\n" +
> " LogicalFilter(condition=[OR(=(130, $0), =(130, $7))])\n" +
> "LogicalTableScan(table=[[CATALOG, SALES, EMP]])\n");
> sql(sql).withConfig(b -> b.withInSubQueryThreshold(1))
> .throws_("java.lang.NullPointerException: scope");
> }{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (CALCITE-4799) SqlXmlFunctionsTest testXmlTransform unit test failed caused by NPE
[
https://issues.apache.org/jira/browse/CALCITE-4799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rui Wang closed CALCITE-4799.
-
> SqlXmlFunctionsTest testXmlTransform unit test failed caused by NPE
> ---
>
> Key: CALCITE-4799
> URL: https://issues.apache.org/jira/browse/CALCITE-4799
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.28.0
>Reporter: duan xiong
>Assignee: duan xiong
>Priority: Major
> Fix For: 1.29.0
>
> Attachments: The Code Image.png
>
>
> Error Info:
> {code:java}
> java.lang.AssertionError: xmlTransform(, <)
> Expected: is org.apache.calcite.runtime.CalciteException: Illegal xslt
> specified : '<'
> but: was
> Expected :is org.apache.calcite.runtime.CalciteException: Illegal xslt
> specified : '<'
> Actual :
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (CALCITE-4783) RelFieldTrimmer incorrectly drops filter condition
[
https://issues.apache.org/jira/browse/CALCITE-4783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rui Wang closed CALCITE-4783.
-
> RelFieldTrimmer incorrectly drops filter condition
> --
>
> Key: CALCITE-4783
> URL: https://issues.apache.org/jira/browse/CALCITE-4783
> Project: Calcite
> Issue Type: Improvement
>Reporter: xzh_dz
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.29.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> {code:java}
> // code placeholder
> org.apache.calcite.test.SqlToRelConverterTest
> @Test void testTrim() {
> final String sql = "select count(*) from emp where ename = '1'";
> final RelNode rel = tester.convertSqlToRel(sql).rel;
> final HepProgramBuilder programBuilder = HepProgram.builder();
> programBuilder.addRuleInstance(CoreRules.FILTER_TO_CALC);
> final HepPlanner planner = new HepPlanner(programBuilder.build());
> planner.setRoot(rel);
> final RelNode calc = planner.findBestExp();
> final List relOptTables = RelOptUtil.findAllTables(calc);
> RelOptSchema relOptSchema = null;
> if (relOptTables.size() != 0) {
> relOptSchema = relOptTables.get(0).getRelOptSchema();
> }
> final RelBuilder relBuilder = RelFactories.LOGICAL_BUILDER.create(
> calc.getCluster(), relOptSchema);
> final RelFieldTrimmer fieldTrimmer = new RelFieldTrimmer(null, relBuilder);
> final RelNode trimmed = fieldTrimmer.trim(calc);
> System.out.println(RelOptUtil.toString(trimmed));
> }
> rel:
> LogicalAggregate(group=[{}], EXPR$0=[COUNT()])
> LogicalProject($f0=[0])
> LogicalFilter(condition=[=($1, '1')])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> trimmed:
> LogicalAggregate(group=[{}], EXPR$0=[COUNT()])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]]){code}
> In this case,RelFieldTrimmer incorrectly drops filter
> condition.`RelNode(trimmed)` is incorrect,there is no predicate condition
> `ename = '1'` in final `RelNode(trimmed)`.During Calc operator trim,
> predicates should not be lost.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (CALCITE-4851) Build gives lots of 'Execution optimizations have been disabled' warnings
[
https://issues.apache.org/jira/browse/CALCITE-4851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rui Wang closed CALCITE-4851.
-
> Build gives lots of 'Execution optimizations have been disabled' warnings
> -
>
> Key: CALCITE-4851
> URL: https://issues.apache.org/jira/browse/CALCITE-4851
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.27.0
> Environment: MacOS
> Gradle 7.2
> Jdk 11
>Reporter: duan xiong
>Assignee: duan xiong
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.29.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Lots of warnings about Execution optimizations have been disabled when build
> CALCITE. For example:
> {noformat}
> Execution optimizations have been disabled for task ':babel:sourcesJar' to
> ensure correctness due to the following reasons:
> - Gradle detected a problem with the following location:
> '/calcite/babel/build/javacc/javaCCMain'.
> Reason: Task ':babel:sourcesJar' uses this output of task ':babel:javaCCMain'
> without declaring an explicit or implicit dependency.
> This can lead to incorrect results being produced, depending on what order
> the tasks are executed. Please refer to
> https://docs.gradle.org/7.2/userguide/validation_problems.html#implicit_dependency
> for more details about this problem.{noformat}
> and
> {noformat}
> Gradle detected a problem with the following location: '/calcite'. Reason:
> Task ':gitProps' uses this output of task ':babel:checkstyleTest' without
> declaring an explicit or implicit dependency.
> This can lead to incorrect results being produced, depending on what order
> the tasks are executed. Please refer to
> https://docs.gradle.org/7.2/userguide/validation_problems.html#implicit_dependency
> for more details about this problem.{noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (CALCITE-4858) Use Log4j2 instead of unsupported Log4j (1.x) in tests
[
https://issues.apache.org/jira/browse/CALCITE-4858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rui Wang closed CALCITE-4858.
-
> Use Log4j2 instead of unsupported Log4j (1.x) in tests
> --
>
> Key: CALCITE-4858
> URL: https://issues.apache.org/jira/browse/CALCITE-4858
> Project: Calcite
> Issue Type: Improvement
>Affects Versions: 1.28.0
>Reporter: Stamatis Zampetakis
>Assignee: Stamatis Zampetakis
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.29.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Currently the logger implementation (for SL4J APIs) that is used in tests is
> Log4j (1.x) via slf4j-log4j12 dependency. Log4j (1.x) has reached [end of
> life in
> 2015|https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces]
> and using it is highly discouraged for multiple reasons (security,
> performance, features, etc.)
> {noformat}
> 5 August 2015 --The Apache Logging Services™ Project Management Committee
> (PMC) has announced that the Log4j™ 1.x logging framework has reached its end
> of life (EOL) and is no longer officially supported.
> {noformat}
> The goal of this JIRA is to use the more modern Log4j2 as the chosen
> implementation for the SLF4J APIs (via log4j-slf4j-impl) in tests. The only
> modules that cannot benefit from this upgrade are Pig/Piglet due to tight
> dependencies to log4j API.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (CALCITE-4875) NVL Function Incorrectly changes nullability field of its operands
[
https://issues.apache.org/jira/browse/CALCITE-4875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rui Wang closed CALCITE-4875.
-
> NVL Function Incorrectly changes nullability field of its operands
> --
>
> Key: CALCITE-4875
> URL: https://issues.apache.org/jira/browse/CALCITE-4875
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.28.0
>Reporter: Jay Narale
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.29.0
>
> Time Spent: 6h 50m
> Remaining Estimate: 0h
>
> We rewrite the NVL function in
> _org/apache/calcite/sql2rel/StandardConvertletTable.java:303_ , during the
> rewrite we currently override the operands' nullability to be NOT NULL which
> is not needed. This causes issues if that operand is pushdown , since the
> input of that operand need not be not nullable whereas we forced that operand
> to be Not nullable.
> We rewrite the nvl function [ NVL(op1, op2) to CASE ( IS NOT NULL (op1),
> op1, op2) ]
> Previously we were wrongly setting final op1, op2 nullability to NOT NULL
> For Example for the query
> select nvl("name", 'undefined') FROM "hr"."emps"
> Using the test framework, (Column "name" is nullable)
> The generated plan before this change is:
> {code:java}
> EnumerableCalc(expr#0..4=[{inputs}], expr#5=[IS NOT NULL($t2)],
> expr#6=[CAST($t2):VARCHAR NOT NULL], expr#7=['undefined':VARCHAR],
> expr#8=[CASE($t5, $t6, $t7)], EXPR$0=[$t8])
> EnumerableTableScan(table=[[hr, emps]])
> {code}
> After this change:
> {code:java}
> EnumerableCalc(expr#0..4=[{inputs}], expr#5=[IS NOT NULL($t2)],
> expr#6=[CAST($t2):VARCHAR], expr#7= ['undefined':VARCHAR], expr#8=[CASE($t5,
> $t6, $t7)], EXPR$0=[$t8])
> EnumerableTableScan(table=[[hr, emps]])
>
> {code}
> If we look at expr#8 , its the CASE described earlier and expr#6 is the
> "name" column.
> As described with this change we can assert that the nullability is preserved
> as nullable as required ( expr#6 is set to Nullable)
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (CALCITE-4917) Add test for 'a IS NOT NULL AND a = b' simplification
[
https://issues.apache.org/jira/browse/CALCITE-4917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rui Wang closed CALCITE-4917.
-
> Add test for 'a IS NOT NULL AND a = b' simplification
> -
>
> Key: CALCITE-4917
> URL: https://issues.apache.org/jira/browse/CALCITE-4917
> Project: Calcite
> Issue Type: Test
> Components: core
>Affects Versions: 1.28.0
>Reporter: Alessandro Solimando
>Assignee: Alessandro Solimando
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.29.0
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> Simplification (from _RexSimplify_ class) is mostly covered in
> {_}RexProgramTest{_}, but tests for expressions of the form "IS NOT NULL(a)
> AND a=b" (with nullable and not nullable types) seem to be missing.
>
> Since I had to write tests to make sure the simplification was as expected, I
> assume others might end up doing the same, and that the tests will both act
> as documentation and it will also protect against regressions.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (CALCITE-4894) MV rewriting fails for conjunctive top expressions in SELECT clause
[
https://issues.apache.org/jira/browse/CALCITE-4894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rui Wang closed CALCITE-4894.
-
> MV rewriting fails for conjunctive top expressions in SELECT clause
> ---
>
> Key: CALCITE-4894
> URL: https://issues.apache.org/jira/browse/CALCITE-4894
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.28.0
>Reporter: Alessandro Solimando
>Assignee: Alessandro Solimando
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.29.0
>
> Time Spent: 5h 20m
> Remaining Estimate: 0h
>
> MV rewrite fails when at least one expression in the project of either the
> view or the query references, directly or indirectly, to more than one field.
> Consider a view with an expression of the form "f between 1 and 3" expression
> (which under the hood becomes "f >= 1 and f <= 3", so effectively referencing
> the same field twice):
> {code:java}
> @Test void testViewProjectWithBetween() {
> sql("select s.\"time_id\", s.\"time_id\" between 1 and 3"
> + " from \"foodmart\".\"sales_fact_1997\" as s"
> + " where s.\"store_id\" = 1",
> "select s.\"time_id\""
> + " from \"foodmart\".\"sales_fact_1997\" as s"
> + " where s.\"store_id\" = 1")
> .withDefaultSchemaSpec(CalciteAssert.SchemaSpec.JDBC_FOODMART)
> .ok();
> }{code}
> It fails as follows:
> {noformat}
> FAILURE 6.9sec, org.apache.calcite.test.MaterializedViewRelOptRulesTest >
> testViewProjectWithBetween()
> java.lang.AssertionError
> at
> org.apache.calcite.rel.rules.materialize.MaterializedViewRule.generateSwapTableColumnReferencesLineage(MaterializedViewRule.java:1046)
> at
> org.apache.calcite.rel.rules.materialize.MaterializedViewRule.rewriteExpressions(MaterializedViewRule.java:1005)
> at
> org.apache.calcite.rel.rules.materialize.MaterializedViewJoinRule.rewriteView(MaterializedViewJoinRule.java:278)
> at
> org.apache.calcite.rel.rules.materialize.MaterializedViewRule.perform(MaterializedViewRule.java:475)
> at
> org.apache.calcite.rel.rules.materialize.MaterializedViewOnlyFilterRule.onMatch(MaterializedViewOnlyFilterRule.java:50)
> at
> org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:239)
> at
> org.apache.calcite.plan.volcano.IterativeRuleDriver.drive(IterativeRuleDriver.java:61)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:523)
> at
> org.apache.calcite.tools.Programs.lambda$standard$3(Programs.java:276)
> at
> org.apache.calcite.tools.Programs$SequenceProgram.run(Programs.java:336)
> at
> org.apache.calcite.test.MaterializedViewRelOptRulesTest.optimize(MaterializedViewRelOptRulesTest.java:1210)
> at
> org.apache.calcite.test.AbstractMaterializedViewTest.checkMaterialize(AbstractMaterializedViewTest.java:109)
> at
> org.apache.calcite.test.AbstractMaterializedViewTest.access$000(AbstractMaterializedViewTest.java:69)
> at
> org.apache.calcite.test.AbstractMaterializedViewTest$Sql.ok(AbstractMaterializedViewTest.java:230)
> at
> org.apache.calcite.test.MaterializedViewRelOptRulesTest.testViewProjectWithBetween(MaterializedViewRelOptRulesTest.java:60){noformat}
>
> Similarly when the same kind of expression is present in the query:
> {code:java}
> @Test void testQueryProjectWithBetween() {
> sql("select *"
> + " from \"foodmart\".\"sales_fact_1997\" as s"
> + " where s.\"store_id\" = 1",
> "select s.\"time_id\" between 1 and 3"
> + " from \"foodmart\".\"sales_fact_1997\" as s"
> + " where s.\"store_id\" = 1")
> .withDefaultSchemaSpec(CalciteAssert.SchemaSpec.JDBC_FOODMART)
> .ok();
> } {code}
> Calcite fails as follows:
> {noformat}
> FAILURE 5.5sec, org.apache.calcite.test.MaterializedViewRelOptRulesTest >
> testQueryProjectWithBetween()
> java.lang.AssertionError
> at
> org.apache.calcite.rel.rules.materialize.MaterializedViewJoinRule.rewriteView(MaterializedViewJoinRule.java:268)
> at
> org.apache.calcite.rel.rules.materialize.MaterializedViewRule.perform(MaterializedViewRule.java:475)
> at
> org.apache.calcite.rel.rules.materialize.MaterializedViewProjectFilterRule.onMatch(MaterializedViewProjectFilterRule.java:53)
> at
> org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:239)
> at
> org.apache.calcite.plan.volcano.IterativeRuleDriver.drive(IterativeRuleDriver.java:61)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:523)
> at
>
[jira] [Closed] (CALCITE-4876) Converting RelNode to SQL with CalciteSqlDialect gets wrong result while EnumerableIntersect is followed by EnumerableLimit
[
https://issues.apache.org/jira/browse/CALCITE-4876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rui Wang closed CALCITE-4876.
-
> Converting RelNode to SQL with CalciteSqlDialect gets wrong result while
> EnumerableIntersect is followed by EnumerableLimit
> ---
>
> Key: CALCITE-4876
> URL: https://issues.apache.org/jira/browse/CALCITE-4876
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.28.0
>Reporter: ZheHu
>Assignee: ZheHu
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.29.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> When I convert the following RelNode to SQL(with CalciteSqlDialect) in
> ToLogicalConverterTest.java:
> {code:java}
> @Test void testIntersect() {
> final RelBuilder builder = builder();
> RelNode rel =
> builder.scan("DEPT")
> .project(builder.field("DEPTNO"))
> .scan("EMP")
> .project(builder.field("DEPTNO"))
> .intersect(true)
> .limit(0, 2)
> .build();
> System.out.println(new
> RelToSqlConverter(SqlDialect.DatabaseProduct.CALCITE.getDialect()).visitRoot(rel).asStatement());
> {code}
> I get:
> {code:java}
> SELECT *
> FROM SELECT `DEPTNO`
> FROM `scott`.`DEPT`
> INTERSECT ALL
> SELECT `DEPTNO`
> FROM `scott`.`EMP`
> FETCH NEXT 2 ROWS ONLY
> {code}
> But the expected SQL should be:
> {code:java}
> SELECT *
> FROM (SELECT `DEPTNO`
> FROM `scott`.`DEPT`
> INTERSECT ALL
> SELECT `DEPTNO`
> FROM `scott`.`EMP`)
> FETCH NEXT 2 ROWS ONLY
> {code}
> Other SetOperators like UNION、MINUS can be converted correctly.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (CALCITE-4884) Provide a new constructor for RelJsonWriter to allow customized JsonBuilder
[
https://issues.apache.org/jira/browse/CALCITE-4884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rui Wang closed CALCITE-4884.
-
> Provide a new constructor for RelJsonWriter to allow customized JsonBuilder
> ---
>
> Key: CALCITE-4884
> URL: https://issues.apache.org/jira/browse/CALCITE-4884
> Project: Calcite
> Issue Type: Improvement
>Reporter: Chunwei Lei
>Assignee: Chunwei Lei
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.29.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Currently JsonBuilder in RelJsonWriter cannot be customized due to it being
> created in the constructor. We can provide a new constructor for
> RelJsonWriter to allow customized JsonBuilder.
> {code:java}
> // code placeholder
> public RelJsonWriter() {
> jsonBuilder = new JsonBuilder();
> relList = jsonBuilder.list();
> relJson = new RelJson(jsonBuilder);
> }
> // the new constrctor suggested.
> public RelJsonWriter(JsonBuilder jsonBuilder) {
> this.jsonBuilder = jsonBuilder;
> relList = jsonBuilder.list();
> relJson = new RelJson(jsonBuilder);
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (CALCITE-4925) AggregateReduceFunctionsRule should accept arbitrary predicates
[
https://issues.apache.org/jira/browse/CALCITE-4925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rui Wang closed CALCITE-4925.
-
> AggregateReduceFunctionsRule should accept arbitrary predicates
> ---
>
> Key: CALCITE-4925
> URL: https://issues.apache.org/jira/browse/CALCITE-4925
> Project: Calcite
> Issue Type: Improvement
>Reporter: Will Noble
>Assignee: Will Noble
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.29.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {{AggregateReduceFunctionsRule}} allows you to specify which functions to
> reduce, but only allows you to specify by function type. For instance, you
> can either reduce all {{SUM}} functions, or no {{SUM}} functions, but not a
> subset of {{SUM}} functions (say, only the {{SUM}} functions with distinct
> keys). Allowing the user to specify an arbitrary predicate would allow us to
> selectively apply the rule to functions without distinct keys, which matters
> in Looker due to the fact that distinct keys cause an aggregate to be
> impossible to roll up, and when that's the case, we'd like to avoid reducing
> the functions for the purpose of aggregate awareness.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (CALCITE-4906) Wrong result for scalar subquery (single value aggregation) from empty input
[
https://issues.apache.org/jira/browse/CALCITE-4906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rui Wang closed CALCITE-4906.
-
> Wrong result for scalar subquery (single value aggregation) from empty input
>
>
> Key: CALCITE-4906
> URL: https://issues.apache.org/jira/browse/CALCITE-4906
> Project: Calcite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.29.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Scalar subqueries from the empty input return non-nullable type and in some
> cases it leads to wrong results. For example:
> {noformat}
> SELECT (SELECT 1 FROM (SELECT NULL) WHERE 1 = 0)
> {noformat}
> Returns {{0}}, but expected {{NULL}} according to the SQL standard:
> {noformat}
> Let SS be a .
> Case:
> a) If the cardinality of SS is greater than 1 (one), then an exception
> condition is raised: cardinality violation.
> b) If the cardinality of SS is 0 (zero), then the value of the subquery> is the null value.
> c) Otherwise, let C be the column of simply contained in
> SS. The value of SS is the value of C in the unique row of the result of the
> .
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (CALCITE-4930) Update log4j2 version to 2.15.0
[ https://issues.apache.org/jira/browse/CALCITE-4930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rui Wang closed CALCITE-4930. - > Update log4j2 version to 2.15.0 > --- > > Key: CALCITE-4930 > URL: https://issues.apache.org/jira/browse/CALCITE-4930 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.28.0 >Reporter: Ada Wong >Assignee: Ada Wong >Priority: Minor > Labels: pull-request-available > Fix For: 1.29.0 > > Time Spent: 50m > Remaining Estimate: 0h > > 2.0 <= Apache log4j2 <= 2.14.1 have a RCE zero day. > [https://www.cyberkendra.com/2021/12/worst-log4j-rce-zeroday-dropped-on.html] > [https://www.lunasec.io/docs/blog/log4j-zero-day/] > [CVE-2021-44228|http://cve.mitre.org/cgi-bin/cvename.cgi?name=2021-44228] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (CALCITE-4895) MAP type in UDF cannot be externalized from json correctly
[
https://issues.apache.org/jira/browse/CALCITE-4895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rui Wang closed CALCITE-4895.
-
> MAP type in UDF cannot be externalized from json correctly
> --
>
> Key: CALCITE-4895
> URL: https://issues.apache.org/jira/browse/CALCITE-4895
> Project: Calcite
> Issue Type: Bug
>Reporter: Chunwei Lei
>Assignee: Chunwei Lei
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.29.0
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> {code:java}
> // code placeholder
> java.lang.RuntimeException: java.lang.RuntimeException:
> java.lang.AssertionError: use createMapType() instead
> at org.apache.calcite.tools.Frameworks.withPrepare(Frameworks.java:193)
> at org.apache.calcite.tools.Frameworks.withPlanner(Frameworks.java:135)
> at org.apache.calcite.tools.Frameworks.withPlanner(Frameworks.java:153)
> at
> org.apache.calcite.plan.RelWriterTest.deserializeAndDump(RelWriterTest.java:1024)
> at
> org.apache.calcite.plan.RelWriterTest.deserializeAndDumpToTextFormat(RelWriterTest.java:1044)
> at
> org.apache.calcite.plan.RelWriterTest.testMapType(RelWriterTest.java:978)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:725)
> at
> org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
> at
> org.junit.jupiter.engine.extension.TimeoutInvocation.proceed(TimeoutInvocation.java:46)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:149)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:140)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:84)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(ExecutableInvoker.java:115)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker.lambda$invoke$0(ExecutableInvoker.java:105)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:104)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:98)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:214)
> at
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:210)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:135)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:66)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:151)
> at
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141)
> at
> org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$9(NodeTestTask.java:139)
> at
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:138)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:95)
> at
>
[jira] [Closed] (CALCITE-4883) The traitset of Exchange operator losses the distribution when externalizing Exchange operator from JSON
[
https://issues.apache.org/jira/browse/CALCITE-4883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rui Wang closed CALCITE-4883.
-
> The traitset of Exchange operator losses the distribution when externalizing
> Exchange operator from JSON
>
>
> Key: CALCITE-4883
> URL: https://issues.apache.org/jira/browse/CALCITE-4883
> Project: Calcite
> Issue Type: Bug
>Reporter: Chunwei Lei
>Assignee: Chunwei Lei
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.29.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> {code:java}
> // code placeholder
> // input.getTraitSet() might not have same distribution as
> input.getDistribution()).
> protected Exchange(RelInput input) {
> this(input.getCluster(), input.getTraitSet(), input.getInput(),
> RelDistributionTraitDef.INSTANCE.canonize(input.getDistribution()));
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (CALCITE-4937) Upgrade Calcite to Avatica 1.20
[ https://issues.apache.org/jira/browse/CALCITE-4937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rui Wang closed CALCITE-4937. - > Upgrade Calcite to Avatica 1.20 > --- > > Key: CALCITE-4937 > URL: https://issues.apache.org/jira/browse/CALCITE-4937 > Project: Calcite > Issue Type: Bug >Affects Versions: 1.28.0 >Reporter: Julian Hyde >Assignee: Julian Hyde >Priority: Major > Fix For: 1.29.0 > > > Upgrade Calcite to Avatica 1.20. 1.20 was [just > released|https://calcite.apache.org/avatica/news/2021/12/13/release-1.20.0/]. > We will need to change the variables that were set in CALCITE-4877 to work > around incompatible changes in Avatica output. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (CALCITE-4928) Decouple Janino from RelMetadataQuery
[ https://issues.apache.org/jira/browse/CALCITE-4928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rui Wang closed CALCITE-4928. - > Decouple Janino from RelMetadataQuery > - > > Key: CALCITE-4928 > URL: https://issues.apache.org/jira/browse/CALCITE-4928 > Project: Calcite > Issue Type: Improvement >Reporter: Jacques Nadeau >Assignee: Jacques Nadeau >Priority: Major > Labels: pull-request-available > Fix For: 1.29.0 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > * After discussion in CALCITE-4879 and CALCITE-4914, lets create a minimally > invasive version of CALCITE-4539 that allows decoupling of Janino. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (CALCITE-4932) Deprecate JdbcCalc and remove JdbcCalcRule
[
https://issues.apache.org/jira/browse/CALCITE-4932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rui Wang closed CALCITE-4932.
-
> Deprecate JdbcCalc and remove JdbcCalcRule
> --
>
> Key: CALCITE-4932
> URL: https://issues.apache.org/jira/browse/CALCITE-4932
> Project: Calcite
> Issue Type: Task
> Components: jdbc-adapter
>Affects Versions: 1.28.0
>Reporter: Francesco Gini
>Assignee: Francesco Gini
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.29.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The jdbc adapter includes a node and rule for {{Calc}} ( {{{}JdbcCal{}}}c a
> {{JdbcCalcRule}} ). {{Calc}} is an operation that is introduced only later in
> the planner to optimise certain code generation and it is not needed for the
> jdbc adapter.
> As it stands the rule {{JdbcCalcRule}} is never triggered because the
> {{Jdbc}} convention rules are applied before the {{Calc}} node is introduced
> in the plan. However, if a user try to use a custom rule set they might end
> up with a {{JdbcCalc}} which introduces problems like the one described in
> https://issues.apache.org/jira/browse/CALCITE-4905 .
> Because {{JdbcCalc}} is not an optimisation needed for jdbc anyway we should
> deprecate {{JdbcCalc}} and its respective rule {{{}JdbcCalcRule{}}}. The rule
> should also be removed from {{JdbcRules.rules}}
> See ticket https://issues.apache.org/jira/browse/CALCITE-4905 for a
> discussion around deprecating {{JdbcCalc}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (CALCITE-4927) Remove deprecated RelBuilder#groupKey(ImmutableBitSet, ImmutableList) clashing with new replacement API
[
https://issues.apache.org/jira/browse/CALCITE-4927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rui Wang closed CALCITE-4927.
-
> Remove deprecated RelBuilder#groupKey(ImmutableBitSet, ImmutableList)
> clashing with new replacement API
> ---
>
> Key: CALCITE-4927
> URL: https://issues.apache.org/jira/browse/CALCITE-4927
> Project: Calcite
> Issue Type: Task
> Components: core
>Affects Versions: 1.28.0
>Reporter: Stamatis Zampetakis
>Assignee: Stamatis Zampetakis
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.29.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The {{RelBuilder#groupKey(ImmutableBitSet, ImmutableList)}} API is marked for
> removal before 2.0.
> {code:java}
> /** @deprecated Use {@link #groupKey(ImmutableBitSet)}
>* or {@link #groupKey(ImmutableBitSet, Iterable)}. */
> @Deprecated // to be removed before 2.0
> public GroupKey groupKey(ImmutableBitSet groupSet,
> @Nullable ImmutableList groupSets)
> {code}
> I would suggest to remove it ASAP due to the fact that it clashes with the
> new replacement API.
> {code:java}
> public GroupKey groupKey(ImmutableBitSet groupSet,
> Iterable groupSets)
> {code}
> Leaving it as is creates ambiguity and requires everybody to upcast to
> {{Iterable}} if they want to use the new API.
> Removing it on the other hand does not seem to affect much backward
> compatibility since callers will automatically use the new API with no
> changes required in their code.
> The main difference is that the deprecated API allows {{groupSets}} to be
> null but if we care so much we can also make the new API to be more
> permissive.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (CALCITE-4898) Upgrading Elasticsearch version from 7.0.1 to 7.15 in Elasticsearch Adapter
[ https://issues.apache.org/jira/browse/CALCITE-4898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rui Wang closed CALCITE-4898. - > Upgrading Elasticsearch version from 7.0.1 to 7.15 in Elasticsearch Adapter > --- > > Key: CALCITE-4898 > URL: https://issues.apache.org/jira/browse/CALCITE-4898 > Project: Calcite > Issue Type: Improvement > Components: elasticsearch-adapter >Affects Versions: 1.28.0 >Reporter: ZheHu >Assignee: ZheHu >Priority: Major > Labels: pull-request-available > Fix For: 1.29.0 > > Time Spent: 4h 20m > Remaining Estimate: 0h > > The current Elasticsearch version in Calcite is 7.0.1, while the latest > released ES version is 7.15.2. > There are many new SQL features added and bugs fixed from 7.0.1 to 7.15. By > upgrading the embedded ES, we can make good use of ES's new features, > especially about DSL, which enable developers to find one more suitable or > effective way to implement features and improve existing functions. > Since low level rest client has good compatibility among 7.x versions, > RestClient is also upgraded to 7.15.2, which is supported currently. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (CALCITE-4929) Add default methods for getDef on metadata handlers
[ https://issues.apache.org/jira/browse/CALCITE-4929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rui Wang closed CALCITE-4929. - > Add default methods for getDef on metadata handlers > --- > > Key: CALCITE-4929 > URL: https://issues.apache.org/jira/browse/CALCITE-4929 > Project: Calcite > Issue Type: Improvement >Reporter: Jacques Nadeau >Priority: Major > Labels: pull-request-available > Fix For: 1.29.0 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > Right now, metadata handler implementations must implement a getDef() method. > The values are singletons next to the interface definitions. This change > proposes making these singletons be returned automatically by default methods > rather than implementers needing to implement these known values. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (CALCITE-4938) Upgrade SQLLine to 1.12.0
[ https://issues.apache.org/jira/browse/CALCITE-4938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rui Wang closed CALCITE-4938. - > Upgrade SQLLine to 1.12.0 > - > > Key: CALCITE-4938 > URL: https://issues.apache.org/jira/browse/CALCITE-4938 > Project: Calcite > Issue Type: Bug >Affects Versions: 1.28.0 >Reporter: Julian Hyde >Assignee: Julian Hyde >Priority: Major > Fix For: 1.29.0 > > > Upgrade SQLLine to 1.12.0. Among [other > things|https://github.com/julianhyde/sqlline/blob/main/HISTORY.md#1120-2021-11-07], > SQLLine 1.12 can run on > [Apple/M1|https://github.com/julianhyde/sqlline/issues/444]. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (CALCITE-4946) Add method RelBuilder.size()
[
https://issues.apache.org/jira/browse/CALCITE-4946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rui Wang closed CALCITE-4946.
-
> Add method RelBuilder.size()
>
>
> Key: CALCITE-4946
> URL: https://issues.apache.org/jira/browse/CALCITE-4946
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.29.0
>
>
> Add method {{{}RelBuilder.size(){}}}, one application of which is to know
> whether it is safe to call {{{}peek(){}}}.
> Also continue the work started in CALCITE-4719, improving support for ARRAY
> query constructor, e.g.
> {code}
> SELECT ARRAY (SELECT ...) AS items
> FROM Orders
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (CALCITE-4941) SemiJoinRule loses hints
[ https://issues.apache.org/jira/browse/CALCITE-4941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rui Wang closed CALCITE-4941. - > SemiJoinRule loses hints > > > Key: CALCITE-4941 > URL: https://issues.apache.org/jira/browse/CALCITE-4941 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.28.0 >Reporter: Ruben Q L >Assignee: Ruben Q L >Priority: Major > Labels: pull-request-available > Fix For: 1.29.0 > > Time Spent: 1h > Remaining Estimate: 0h > > SemiJoinRule does not propagate the (potential) hints from the input Join to > the output SemiJoin -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (CALCITE-4939) Upgrade log4j2 version to 2.16.0
[ https://issues.apache.org/jira/browse/CALCITE-4939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rui Wang closed CALCITE-4939. - > Upgrade log4j2 version to 2.16.0 > > > Key: CALCITE-4939 > URL: https://issues.apache.org/jira/browse/CALCITE-4939 > Project: Calcite > Issue Type: Improvement >Reporter: Stamatis Zampetakis >Assignee: Stamatis Zampetakis >Priority: Major > Labels: pull-request-available > Fix For: 1.29.0 > > Time Spent: 40m > Remaining Estimate: 0h > > The [2.16.0 > release|https://logging.apache.org/log4j/2.x/changes-report.html#a2.16.0] has > two additional fixes related to CVE-2021-4422 for hardening security. Calcite > uses Log4j2 only for testing purposes so the risk is minimal but it would be > good to have them. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (CALCITE-4948) Revert Elasticsearch to 7.10.2 to avoid extra repo and category X license
[ https://issues.apache.org/jira/browse/CALCITE-4948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rui Wang closed CALCITE-4948. - > Revert Elasticsearch to 7.10.2 to avoid extra repo and category X license > - > > Key: CALCITE-4948 > URL: https://issues.apache.org/jira/browse/CALCITE-4948 > Project: Calcite > Issue Type: Improvement > Components: elasticsearch-adapter >Reporter: Jacques Nadeau >Assignee: Jacques Nadeau >Priority: Major > Labels: pull-request-available > Fix For: 1.29.0 > > Time Spent: 50m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (CALCITE-4950) Upgrade log4j2 version 2.17.0
[ https://issues.apache.org/jira/browse/CALCITE-4950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rui Wang closed CALCITE-4950. - > Upgrade log4j2 version 2.17.0 > - > > Key: CALCITE-4950 > URL: https://issues.apache.org/jira/browse/CALCITE-4950 > Project: Calcite > Issue Type: Task >Reporter: Stamatis Zampetakis >Assignee: Stamatis Zampetakis >Priority: Minor > Labels: pull-request-available > Fix For: 1.29.0 > > Time Spent: 20m > Remaining Estimate: 0h > > The [2.17.0 > release|https://logging.apache.org/log4j/2.x/changes-report.html#a2.17.0] > fixes a new security vulnerability CVE-2021-45105. Calcite is not impacted > cause log4j2 is used only for testing purposes. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (CALCITE-4955) Release Calcite 1.29.0
Rui Wang created CALCITE-4955: - Summary: Release Calcite 1.29.0 Key: CALCITE-4955 URL: https://issues.apache.org/jira/browse/CALCITE-4955 Project: Calcite Issue Type: Task Reporter: Rui Wang Assignee: Rui Wang -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (CALCITE-4737) Add Volcano visualizer for debugging
[ https://issues.apache.org/jira/browse/CALCITE-4737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17461037#comment-17461037 ] Rui Wang edited comment on CALCITE-4737 at 12/16/21, 8:40 PM: -- Please considering merging this PR soon if you want it to be in 1.29 as I plan to lock main branch in a few days :) was (Author: amaliujia): Please considering merging this PR soon if you want to be in 1.29 as I plan to lock main branch in a few days :) > Add Volcano visualizer for debugging > > > Key: CALCITE-4737 > URL: https://issues.apache.org/jira/browse/CALCITE-4737 > Project: Calcite > Issue Type: New Feature >Reporter: Julian Hyde >Assignee: Thomas Rebele >Priority: Major > Labels: pull-request-available > Fix For: 1.29.0 > > Time Spent: 8h 20m > Remaining Estimate: 0h > > Add Volcano visualizer for debugging. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (CALCITE-4737) Add Volcano visualizer for debugging
[ https://issues.apache.org/jira/browse/CALCITE-4737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17461037#comment-17461037 ] Rui Wang commented on CALCITE-4737: --- Please considering merging this PR soon if you want to be in 1.29 as I plan to lock main branch in a few days :) > Add Volcano visualizer for debugging > > > Key: CALCITE-4737 > URL: https://issues.apache.org/jira/browse/CALCITE-4737 > Project: Calcite > Issue Type: New Feature >Reporter: Julian Hyde >Assignee: Thomas Rebele >Priority: Major > Labels: pull-request-available > Fix For: 1.29.0 > > Time Spent: 8h 20m > Remaining Estimate: 0h > > Add Volcano visualizer for debugging. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (CALCITE-4927) Remove deprecated RelBuilder#groupKey(ImmutableBitSet, ImmutableList) clashing with new replacement API
[
https://issues.apache.org/jira/browse/CALCITE-4927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rui Wang resolved CALCITE-4927.
---
Resolution: Fixed
> Remove deprecated RelBuilder#groupKey(ImmutableBitSet, ImmutableList)
> clashing with new replacement API
> ---
>
> Key: CALCITE-4927
> URL: https://issues.apache.org/jira/browse/CALCITE-4927
> Project: Calcite
> Issue Type: Task
> Components: core
>Affects Versions: 1.28.0
>Reporter: Stamatis Zampetakis
>Assignee: Stamatis Zampetakis
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.29.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The {{RelBuilder#groupKey(ImmutableBitSet, ImmutableList)}} API is marked for
> removal before 2.0.
> {code:java}
> /** @deprecated Use {@link #groupKey(ImmutableBitSet)}
>* or {@link #groupKey(ImmutableBitSet, Iterable)}. */
> @Deprecated // to be removed before 2.0
> public GroupKey groupKey(ImmutableBitSet groupSet,
> @Nullable ImmutableList groupSets)
> {code}
> I would suggest to remove it ASAP due to the fact that it clashes with the
> new replacement API.
> {code:java}
> public GroupKey groupKey(ImmutableBitSet groupSet,
> Iterable groupSets)
> {code}
> Leaving it as is creates ambiguity and requires everybody to upcast to
> {{Iterable}} if they want to use the new API.
> Removing it on the other hand does not seem to affect much backward
> compatibility since callers will automatically use the new API with no
> changes required in their code.
> The main difference is that the deprecated API allows {{groupSets}} to be
> null but if we care so much we can also make the new API to be more
> permissive.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (CALCITE-4769) Does Dental Care Important? Check This Out!
[ https://issues.apache.org/jira/browse/CALCITE-4769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17413591#comment-17413591 ] Rui Wang commented on CALCITE-4769: --- [~hyuan] Is it possible to delete this JIRA completely? Plus remove the JIRA permission from this creator? > Does Dental Care Important? Check This Out! > --- > > Key: CALCITE-4769 > URL: https://issues.apache.org/jira/browse/CALCITE-4769 > Project: Calcite > Issue Type: Bug >Reporter: dentitox teeth >Priority: Minor > > Despite the fact that one in five adults says that someone’s smile is the > first thing they notice, the large majority of adults completely overlook the > health of their teeth. Plus, believe it or not, the health of your teeth and > mouth plays an important role in your overall health. That’s why it is > important to maintain proper dental hygiene and do what you can to improve > your oral health. > There’s now a supplement on the market that can do both for you. It’s called > Dentiox Pro, and it’s highly recommended by virtually every dental > professional. If you’re looking to improve your dental health and want a > beautiful smile, then look no further – there’s no better product on the > market than Dentiox Teeth. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4636) Wrong RelCollation if a field in GROUP BY appears in ORDER BY of WITHIN GROUP clause
[
https://issues.apache.org/jira/browse/CALCITE-4636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17366767#comment-17366767
]
Rui Wang commented on CALCITE-4636:
---
No :) I think that was my fault. When I merged the commit I should re-word the
commit message to provide more context. Sometimes I forget to highlight the
problem.
> Wrong RelCollation if a field in GROUP BY appears in ORDER BY of WITHIN GROUP
> clause
>
>
> Key: CALCITE-4636
> URL: https://issues.apache.org/jira/browse/CALCITE-4636
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Rafay A
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.28.0
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> If we run this query:
> {code:java}
> select regionkey, collect(regionkey)
> within group (order by regionkey)
> from (SELECT * FROM (VALUES('blah','blah','blah',1,1)) as
> TBL(f1,f2,f3,nationkey,regionkey))
> group by regionkey
> {code}
>
> We see that we are ordering by the same field as the group by field
> (regionkey). Now the query may be non-sensicle as there is no point of
> collecting the same field with in the same group, but syntactically its a
> valid SQL and should produce correct plan, but it generates this plan instead:
> {code:java}
> LogicalAggregate(group=[{0}], EXPR$1=[COLLECT($0) WITHIN GROUP ([1])])
> LogicalProject(REGIONKEY=[$4], F1=[$0])
> LogicalProject(F1=[$0], F2=[$1], F3=[$2], NATIONKEY=[$3], REGIONKEY=[$4])
> LogicalValues(tuples=[[{ 'blah', 'blah', 'blah', 1, 1 }]])
> {code}
>
> If we run the following *good* query, it generates correct plan:
>
> {code:java}
> select nationkey, collect(regionkey)
> within group (order by regionkey)
> from (SELECT * FROM (VALUES('blah','blah','blah',1,1)) as
> TBL(f1,f2,f3,nationkey,regionkey))
> group by regionkey{code}
>
> Generated plan:
> {noformat}
> LogicalAggregate(group=[{0}], EXPR$1=[COLLECT($1) WITHIN GROUP ([1])])
> LogicalProject(NATIONKEY=[$3], REGIONKEY=[$4])
> LogicalProject(F1=[$0], F2=[$1], F3=[$2], NATIONKEY=[$3], REGIONKEY=[$4])
> LogicalValues(tuples=[[{ 'blah', 'blah', 'blah', 1, 1 }]]){noformat}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4636) Wrong RelCollation if a field in GROUP BY appears in ORDER BY of WITHIN GROUP clause
[
https://issues.apache.org/jira/browse/CALCITE-4636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17366729#comment-17366729
]
Rui Wang commented on CALCITE-4636:
---
O I see. That makes sense. I think the message starting with what is the
problem then have necessary context (or the approach to fix) makes most of the
sense.
> Wrong RelCollation if a field in GROUP BY appears in ORDER BY of WITHIN GROUP
> clause
>
>
> Key: CALCITE-4636
> URL: https://issues.apache.org/jira/browse/CALCITE-4636
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Rafay A
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.28.0
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> If we run this query:
> {code:java}
> select regionkey, collect(regionkey)
> within group (order by regionkey)
> from (SELECT * FROM (VALUES('blah','blah','blah',1,1)) as
> TBL(f1,f2,f3,nationkey,regionkey))
> group by regionkey
> {code}
>
> We see that we are ordering by the same field as the group by field
> (regionkey). Now the query may be non-sensicle as there is no point of
> collecting the same field with in the same group, but syntactically its a
> valid SQL and should produce correct plan, but it generates this plan instead:
> {code:java}
> LogicalAggregate(group=[{0}], EXPR$1=[COLLECT($0) WITHIN GROUP ([1])])
> LogicalProject(REGIONKEY=[$4], F1=[$0])
> LogicalProject(F1=[$0], F2=[$1], F3=[$2], NATIONKEY=[$3], REGIONKEY=[$4])
> LogicalValues(tuples=[[{ 'blah', 'blah', 'blah', 1, 1 }]])
> {code}
>
> If we run the following *good* query, it generates correct plan:
>
> {code:java}
> select nationkey, collect(regionkey)
> within group (order by regionkey)
> from (SELECT * FROM (VALUES('blah','blah','blah',1,1)) as
> TBL(f1,f2,f3,nationkey,regionkey))
> group by regionkey{code}
>
> Generated plan:
> {noformat}
> LogicalAggregate(group=[{0}], EXPR$1=[COLLECT($1) WITHIN GROUP ([1])])
> LogicalProject(NATIONKEY=[$3], REGIONKEY=[$4])
> LogicalProject(F1=[$0], F2=[$1], F3=[$2], NATIONKEY=[$3], REGIONKEY=[$4])
> LogicalValues(tuples=[[{ 'blah', 'blah', 'blah', 1, 1 }]]){noformat}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-4616) AggregateUnionTransposeRule causes row type mismatch when some inputs have unique grouping key
[
https://issues.apache.org/jira/browse/CALCITE-4616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17363864#comment-17363864
]
Rui Wang edited comment on CALCITE-4616 at 6/15/21, 7:21 PM:
-
Ah I see it now: if all inputs on a column has unique key, then having agg on
each inputs will work as one input contain a key that other inputs does not
have (thus agg on that single input is ok).
However, per the added test case, I am still confused: if we say that all
inputs have unique keys thus we push down agg, then why we still need the top
agg:
{code:java}
1: Aggregate[group=a, SUM(b)]
2: Union
3: Aggregate[group=a, SUM(b)]
4:Input1[a, b, c]
5: Aggregate[group=a, SUM(b)]
6:Input2[a, b, c]
{code}
was (Author: amaliujia):
Ah I see it now: if all inputs on a column has unique key, then having agg on
each inputs will work as one input contain a key that other inputs does not
have (thus agg on that single input is ok).
However, per the added test case, I am still confused: if we say that all
inputs have unique keys thus we push down agg, then why we still need the top
agg:
1: Aggregate[group=a, SUM(b)]
2: Union
3: Aggregate[group=a, SUM(b)]
4:Input1[a, b, c]
5: Aggregate[group=a, SUM(b)]
6:Input2[a, b, c]
> AggregateUnionTransposeRule causes row type mismatch when some inputs have
> unique grouping key
> --
>
> Key: CALCITE-4616
> URL: https://issues.apache.org/jira/browse/CALCITE-4616
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.26.0
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.28.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Consider the following relational tree:
> {code}
> 1: Aggregate[group=a, SUM(b)]
> 2: Union
> 3: Input1[a, b, c]
> 4: Input2[a, b, c]
> {code}
> It may happen, that {{Input1}} has a unique key on {{[a]}}. In this case,
> Apache Calcite, will not install the {{Aggregate}} on top of it, which leads
> to the following tree:
> {code}
> 1: Aggregate[group=a, SUM(b)]
> 2: Union
> 3: Input1[a, b, c]
> 4: Aggregate[group=a, SUM(b)]
> 5: Input2[a, b, c]
> {code}
> Obviously, the tree is incorrect, because {{Union}} inputs now have different
> row types.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-4616) AggregateUnionTransposeRule causes row type mismatch when some inputs have unique grouping key
[
https://issues.apache.org/jira/browse/CALCITE-4616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17363864#comment-17363864
]
Rui Wang edited comment on CALCITE-4616 at 6/15/21, 7:21 PM:
-
Ah I see it now: if all inputs on a column has unique key, then having agg on
each inputs will work as one input contain a key that other inputs does not
have (thus agg on that single input is ok).
However, per the added test case, I am still confused: if we say that all
inputs have unique keys thus we push down agg, then why we still need the top
agg:
1: Aggregate[group=a, SUM(b)]
2: Union
3: Aggregate[group=a, SUM(b)]
4:Input1[a, b, c]
5: Aggregate[group=a, SUM(b)]
6:Input2[a, b, c]
was (Author: amaliujia):
Ah I see it now: if all inputs on a column has unique key, then having agg on
each inputs will work as one input contain a key that other inputs does not
have (thus agg on that single input is ok).
However, per the added test case, I am still confused: if we say that all
inputs have unique keys thus we push down agg, then why we still need the top
agg?
> AggregateUnionTransposeRule causes row type mismatch when some inputs have
> unique grouping key
> --
>
> Key: CALCITE-4616
> URL: https://issues.apache.org/jira/browse/CALCITE-4616
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.26.0
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.28.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Consider the following relational tree:
> {code}
> 1: Aggregate[group=a, SUM(b)]
> 2: Union
> 3: Input1[a, b, c]
> 4: Input2[a, b, c]
> {code}
> It may happen, that {{Input1}} has a unique key on {{[a]}}. In this case,
> Apache Calcite, will not install the {{Aggregate}} on top of it, which leads
> to the following tree:
> {code}
> 1: Aggregate[group=a, SUM(b)]
> 2: Union
> 3: Input1[a, b, c]
> 4: Aggregate[group=a, SUM(b)]
> 5: Input2[a, b, c]
> {code}
> Obviously, the tree is incorrect, because {{Union}} inputs now have different
> row types.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-4616) AggregateUnionTransposeRule causes row type mismatch when some inputs have unique grouping key
[
https://issues.apache.org/jira/browse/CALCITE-4616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17363864#comment-17363864
]
Rui Wang edited comment on CALCITE-4616 at 6/15/21, 7:20 PM:
-
Ah I see it now: if all inputs on a column has unique key, then having agg on
each inputs will work as one input contain a key that other inputs does not
have (thus agg on that single input is ok).
However, per the added test case, I am still confused: if we say that all
inputs have unique keys thus we push down agg, then why we still need the top
agg?
was (Author: amaliujia):
Ah I see it now: if all inputs on a column has unique key, then having agg on
each inputs will work as one input contain a key that other inputs does not
have (thus agg on that single input is ok).
> AggregateUnionTransposeRule causes row type mismatch when some inputs have
> unique grouping key
> --
>
> Key: CALCITE-4616
> URL: https://issues.apache.org/jira/browse/CALCITE-4616
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.26.0
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.28.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Consider the following relational tree:
> {code}
> 1: Aggregate[group=a, SUM(b)]
> 2: Union
> 3: Input1[a, b, c]
> 4: Input2[a, b, c]
> {code}
> It may happen, that {{Input1}} has a unique key on {{[a]}}. In this case,
> Apache Calcite, will not install the {{Aggregate}} on top of it, which leads
> to the following tree:
> {code}
> 1: Aggregate[group=a, SUM(b)]
> 2: Union
> 3: Input1[a, b, c]
> 4: Aggregate[group=a, SUM(b)]
> 5: Input2[a, b, c]
> {code}
> Obviously, the tree is incorrect, because {{Union}} inputs now have different
> row types.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4616) AggregateUnionTransposeRule causes row type mismatch when some inputs have unique grouping key
[
https://issues.apache.org/jira/browse/CALCITE-4616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17363864#comment-17363864
]
Rui Wang commented on CALCITE-4616:
---
Ah I see it now: if all inputs on a column has unique key, then having agg on
each inputs will work as one input contain a key that other inputs does not
have (thus agg on that single input is ok).
> AggregateUnionTransposeRule causes row type mismatch when some inputs have
> unique grouping key
> --
>
> Key: CALCITE-4616
> URL: https://issues.apache.org/jira/browse/CALCITE-4616
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.26.0
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.28.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Consider the following relational tree:
> {code}
> 1: Aggregate[group=a, SUM(b)]
> 2: Union
> 3: Input1[a, b, c]
> 4: Input2[a, b, c]
> {code}
> It may happen, that {{Input1}} has a unique key on {{[a]}}. In this case,
> Apache Calcite, will not install the {{Aggregate}} on top of it, which leads
> to the following tree:
> {code}
> 1: Aggregate[group=a, SUM(b)]
> 2: Union
> 3: Input1[a, b, c]
> 4: Aggregate[group=a, SUM(b)]
> 5: Input2[a, b, c]
> {code}
> Obviously, the tree is incorrect, because {{Union}} inputs now have different
> row types.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4616) AggregateUnionTransposeRule causes row type mismatch when some inputs have unique grouping key
[
https://issues.apache.org/jira/browse/CALCITE-4616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17363830#comment-17363830
]
Rui Wang commented on CALCITE-4616:
---
The PR seems straightforward: pushing down agg when all inputs have the unique
key. But I am having troubles to understand why unique keys can lead to push
down agg?
> AggregateUnionTransposeRule causes row type mismatch when some inputs have
> unique grouping key
> --
>
> Key: CALCITE-4616
> URL: https://issues.apache.org/jira/browse/CALCITE-4616
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.26.0
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.28.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Consider the following relational tree:
> {code}
> 1: Aggregate[group=a, SUM(b)]
> 2: Union
> 3: Input1[a, b, c]
> 4: Input2[a, b, c]
> {code}
> It may happen, that {{Input1}} has a unique key on {{[a]}}. In this case,
> Apache Calcite, will not install the {{Aggregate}} on top of it, which leads
> to the following tree:
> {code}
> 1: Aggregate[group=a, SUM(b)]
> 2: Union
> 3: Input1[a, b, c]
> 4: Aggregate[group=a, SUM(b)]
> 5: Input2[a, b, c]
> {code}
> Obviously, the tree is incorrect, because {{Union}} inputs now have different
> row types.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CALCITE-4636) Wrong RelCollation if a field in Group by appears in Order by of Within Group clause
[
https://issues.apache.org/jira/browse/CALCITE-4636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rui Wang resolved CALCITE-4636.
---
Fix Version/s: 1.28.0
Resolution: Fixed
> Wrong RelCollation if a field in Group by appears in Order by of Within Group
> clause
>
>
> Key: CALCITE-4636
> URL: https://issues.apache.org/jira/browse/CALCITE-4636
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Rafay A
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.28.0
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> If we run this query:
> {code:java}
> select regionkey, collect(regionkey)
> within group (order by regionkey)
> from (SELECT * FROM (VALUES('blah','blah','blah',1,1)) as
> TBL(f1,f2,f3,nationkey,regionkey))
> group by regionkey
> {code}
>
> We see that we are ordering by the same field as the group by field
> (regionkey). Now the query may be non-sensicle as there is no point of
> collecting the same field with in the same group, but syntactically its a
> valid SQL and should produce correct plan, but it generates this plan instead:
> {code:java}
> LogicalAggregate(group=[{0}], EXPR$1=[COLLECT($0) WITHIN GROUP ([1])])
> LogicalProject(REGIONKEY=[$4], F1=[$0])
> LogicalProject(F1=[$0], F2=[$1], F3=[$2], NATIONKEY=[$3], REGIONKEY=[$4])
> LogicalValues(tuples=[[{ 'blah', 'blah', 'blah', 1, 1 }]])
> {code}
>
> If we run the following *good* query, it generates correct plan:
>
> {code:java}
> select nationkey, collect(regionkey)
> within group (order by regionkey)
> from (SELECT * FROM (VALUES('blah','blah','blah',1,1)) as
> TBL(f1,f2,f3,nationkey,regionkey))
> group by regionkey{code}
>
> Generated plan:
> {noformat}
> LogicalAggregate(group=[{0}], EXPR$1=[COLLECT($1) WITHIN GROUP ([1])])
> LogicalProject(NATIONKEY=[$3], REGIONKEY=[$4])
> LogicalProject(F1=[$0], F2=[$1], F3=[$2], NATIONKEY=[$3], REGIONKEY=[$4])
> LogicalValues(tuples=[[{ 'blah', 'blah', 'blah', 1, 1 }]]){noformat}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4636) Wrong RelCollation if a field in Group by appears in Order by of Within Group clause
[
https://issues.apache.org/jira/browse/CALCITE-4636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17362620#comment-17362620
]
Rui Wang commented on CALCITE-4636:
---
Fixed via
https://github.com/apache/calcite/commit/4e679f03771c89ffa463051b5698ead1d935748b.
Thanks [~Rafay]!
> Wrong RelCollation if a field in Group by appears in Order by of Within Group
> clause
>
>
> Key: CALCITE-4636
> URL: https://issues.apache.org/jira/browse/CALCITE-4636
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Rafay A
>Priority: Major
> Labels: pull-request-available
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> If we run this query:
> {code:java}
> select regionkey, collect(regionkey)
> within group (order by regionkey)
> from (SELECT * FROM (VALUES('blah','blah','blah',1,1)) as
> TBL(f1,f2,f3,nationkey,regionkey))
> group by regionkey
> {code}
>
> We see that we are ordering by the same field as the group by field
> (regionkey). Now the query may be non-sensicle as there is no point of
> collecting the same field with in the same group, but syntactically its a
> valid SQL and should produce correct plan, but it generates this plan instead:
> {code:java}
> LogicalAggregate(group=[{0}], EXPR$1=[COLLECT($0) WITHIN GROUP ([1])])
> LogicalProject(REGIONKEY=[$4], F1=[$0])
> LogicalProject(F1=[$0], F2=[$1], F3=[$2], NATIONKEY=[$3], REGIONKEY=[$4])
> LogicalValues(tuples=[[{ 'blah', 'blah', 'blah', 1, 1 }]])
> {code}
>
> If we run the following *good* query, it generates correct plan:
>
> {code:java}
> select nationkey, collect(regionkey)
> within group (order by regionkey)
> from (SELECT * FROM (VALUES('blah','blah','blah',1,1)) as
> TBL(f1,f2,f3,nationkey,regionkey))
> group by regionkey{code}
>
> Generated plan:
> {noformat}
> LogicalAggregate(group=[{0}], EXPR$1=[COLLECT($1) WITHIN GROUP ([1])])
> LogicalProject(NATIONKEY=[$3], REGIONKEY=[$4])
> LogicalProject(F1=[$0], F2=[$1], F3=[$2], NATIONKEY=[$3], REGIONKEY=[$4])
> LogicalValues(tuples=[[{ 'blah', 'blah', 'blah', 1, 1 }]]){noformat}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4606) Test case "countStar" throws exception in AggregationTest of elastic-search adapter
[
https://issues.apache.org/jira/browse/CALCITE-4606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17360228#comment-17360228
]
Rui Wang commented on CALCITE-4606:
---
[~jackyyin]
Will you still use this JIRA to track range query support or you will create a
new JIRA?
> Test case "countStar" throws exception in AggregationTest of elastic-search
> adapter
> ---
>
> Key: CALCITE-4606
> URL: https://issues.apache.org/jira/browse/CALCITE-4606
> Project: Calcite
> Issue Type: Bug
> Components: elasticsearch-adapter
>Affects Versions: 1.26.0
>Reporter: Jacky Yin
>Priority: Critical
> Labels: pull-request-available
> Time Spent: 3h
> Remaining Estimate: 0h
>
> Currently, the "AggregationTest" of elastic-search adapter is disabled. If we
> enable it, the test case "countStar" will throw exception as below. It is
> because that the filter "cat1 in ('a', 'b')" will be simplified from
> "[OR(=($0, 'a'), =($0, 'b'))]" to "[SEARCH(ITEM($0, 'cat1'), Sarg['a',
> 'b']:CHAR(1))]" which is not supported by PredicateAnalyzerTranslator of
> ElasticSearchFilter.
> {noformat}
> Error while executing SQL "select count(*) from view where cat1 in ('a',
> 'b')": Unable to implement ElasticsearchToEnumerableConverter: rowcount =
> 1.0, cumulative cost = \{12.7125 rows, 20.203 cpu, 0.0 io}, id =
> 262Error while executing SQL "select count(*) from view where cat1 in ('a',
> 'b')": Unable to implement ElasticsearchToEnumerableConverter: rowcount =
> 1.0, cumulative cost = \{12.7125 rows, 20.203 cpu, 0.0 io}, id =
> 262 ElasticsearchAggregate(group=[{}], EXPR$0=[COUNT()]): rowcount = 1.0,
> cumulative cost = \{12.6125 rows, 20.1 cpu, 0.0 io}, id = 260
> ElasticsearchFilter(condition=[SEARCH(ITEM($0, 'cat1'), Sarg['a',
> 'b']:CHAR(1))]): rowcount = 25.0, cumulative cost = \{12.5 rows, 20.1 cpu,
> 0.0 io}, id = 258 ElasticsearchTableScan(table=[[elastic, aggs]]):
> rowcount = 100.0, cumulative cost = \{10.0 rows, 10.101 cpu, 0.0
> io}, id = 182
> java.sql.SQLException: Error while executing SQL "select count(*) from view
> where cat1 in ('a', 'b')": Unable to implement
> ElasticsearchToEnumerableConverter: rowcount = 1.0, cumulative cost =
> \{12.7125 rows, 20.203 cpu, 0.0 io}, id = 262
> ElasticsearchAggregate(group=[{}], EXPR$0=[COUNT()]): rowcount = 1.0,
> cumulative cost = \{12.6125 rows, 20.1 cpu, 0.0 io}, id = 260
> ElasticsearchFilter(condition=[SEARCH(ITEM($0, 'cat1'), Sarg['a',
> 'b']:CHAR(1))]): rowcount = 25.0, cumulative cost = \{12.5 rows, 20.1 cpu,
> 0.0 io}, id = 258 ElasticsearchTableScan(table=[[elastic, aggs]]):
> rowcount = 100.0, cumulative cost = \{10.0 rows, 10.101 cpu, 0.0
> io}, id = 182
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56) at
> org.apache.calcite.avatica.Helper.createException(Helper.java:41) at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:163)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:227)
> at org.apache.calcite.test.CalciteAssert.assertQuery(CalciteAssert.java:535)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.lambda$returns$1(CalciteAssert.java:1547)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.withConnection(CalciteAssert.java:1486)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1545)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1535)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1498)
> at
> org.apache.calcite.adapter.elasticsearch.AggregationTest.countStar(AggregationTest.java:132)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498) at
> org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:675)
> at
> org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:125)
> at
> org.junit.jupiter.engine.extension.TimeoutInvocation.proceed(TimeoutInvocation.java:46)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:139)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:131)
> at
>
[jira] [Comment Edited] (CALCITE-4568) Tempura: extending Calcite into an incremental query optimizer
[ https://issues.apache.org/jira/browse/CALCITE-4568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17345888#comment-17345888 ] Rui Wang edited comment on CALCITE-4568 at 5/17/21, 6:02 AM: - [~botong] I started to check https://github.com/clickdatatech/cost-based-incremental-optimizer and the current challeage is that not all tests case can pass and there are checkstyle violvations (for example, mvn clean package -pl core). So to confirm, you are working on a version that is rebased to master at least (so it switches to gradle based project)? was (Author: amaliujia): [~botong] I started to check https://github.com/clickdatatech/cost-based-incremental-optimizer and currently challeage is that not all tests case can pass and there are checkstyle violvations (for example, mvn clean package -pl core). So to confirm, you are working on a version that is rebased to master at least (so it switches to gradle based project)? > Tempura: extending Calcite into an incremental query optimizer > -- > > Key: CALCITE-4568 > URL: https://issues.apache.org/jira/browse/CALCITE-4568 > Project: Calcite > Issue Type: New Feature >Reporter: Botong Huang >Priority: Major > > As discussed in the email thread, this is an attempt to extend the Calcite > optimizer into a general incremental query optimizer, based on our research > paper published in VLDB 2021: > Tempura: a general cost-based optimizer framework for incremental data > processing > To our best knowledge, this is the first general cost-based incremental > optimizer that can find the best plan across multiple families of incremental > computing methods, including IVM, Streaming, DBToaster, etc. Experiments (in > the paper) shows that the generated best plan is consistently much better > than the plans from each individual method alone. > In general, incremental query planning is central to database view > maintenance and stream processing systems, and are being adopted in active > databases, resumable query execution, approximate query processing, etc. We > are hoping that this feature can help widening the spectrum of Calcite, > solicit more use cases and adoption of Calcite. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4568) Tempura: extending Calcite into an incremental query optimizer
[ https://issues.apache.org/jira/browse/CALCITE-4568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17345888#comment-17345888 ] Rui Wang commented on CALCITE-4568: --- [~botong] I started to check https://github.com/clickdatatech/cost-based-incremental-optimizer and currently challeage is that not all tests case can pass and there are checkstyle violvations (for example, mvn clean package -pl core). So to confirm, you are working on a version that is rebased to master at least (so it switches to gradle based project)? > Tempura: extending Calcite into an incremental query optimizer > -- > > Key: CALCITE-4568 > URL: https://issues.apache.org/jira/browse/CALCITE-4568 > Project: Calcite > Issue Type: New Feature >Reporter: Botong Huang >Priority: Major > > As discussed in the email thread, this is an attempt to extend the Calcite > optimizer into a general incremental query optimizer, based on our research > paper published in VLDB 2021: > Tempura: a general cost-based optimizer framework for incremental data > processing > To our best knowledge, this is the first general cost-based incremental > optimizer that can find the best plan across multiple families of incremental > computing methods, including IVM, Streaming, DBToaster, etc. Experiments (in > the paper) shows that the generated best plan is consistently much better > than the plans from each individual method alone. > In general, incremental query planning is central to database view > maintenance and stream processing systems, and are being adopted in active > databases, resumable query execution, approximate query processing, etc. We > are hoping that this feature can help widening the spectrum of Calcite, > solicit more use cases and adoption of Calcite. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4538) Make CalcRelSplitter constructor public.
[ https://issues.apache.org/jira/browse/CALCITE-4538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17302866#comment-17302866 ] Rui Wang commented on CALCITE-4538: --- cc [~julianhyde] any comment on this JIRA? I see that CalcRelSplitter was written back (or even before) 2013 so I am wondering whether this class's mission has changed since then? > Make CalcRelSplitter constructor public. > > > Key: CALCITE-4538 > URL: https://issues.apache.org/jira/browse/CALCITE-4538 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Kyle Weaver >Priority: Major > > CalcRelSplitter is a public class, but its constructor is package-private. > We'd like to implement this class in Beam, which would require making the > constructor public. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4533) Fix handling of REPLACE and IF NOT EXISTS keywords for CREATE TABLE/SCHEMA commands
[
https://issues.apache.org/jira/browse/CALCITE-4533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17300976#comment-17300976
]
Rui Wang commented on CALCITE-4533:
---
thanks for the suggestion :)
> Fix handling of REPLACE and IF NOT EXISTS keywords for CREATE TABLE/SCHEMA
> commands
> ---
>
> Key: CALCITE-4533
> URL: https://issues.apache.org/jira/browse/CALCITE-4533
> Project: Calcite
> Issue Type: Bug
> Components: server
>Affects Versions: 1.26.0
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
> Labels: pull-request-available
> Time Spent: 4h
> Remaining Estimate: 0h
>
> Presently, the {{ServerDdlExecutor}} incorrectly process some keywords:
> # {{CREATE SCHEMA IF NOT EXISTS}} overwrites the existing schema
> # {{CREATE OR REPLACE TABLE}} doesn't replace the table if the table exists
> The goal of this ticket is to unify the handling of {{IF NOT EXISTS}} and
> {{REPLACE}} keywords for these two commands.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CALCITE-4533) Fix handling of REPLACE and IF NOT EXISTS keywords for CREATE TABLE/SCHEMA commands
[
https://issues.apache.org/jira/browse/CALCITE-4533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rui Wang resolved CALCITE-4533.
---
Resolution: Fixed
> Fix handling of REPLACE and IF NOT EXISTS keywords for CREATE TABLE/SCHEMA
> commands
> ---
>
> Key: CALCITE-4533
> URL: https://issues.apache.org/jira/browse/CALCITE-4533
> Project: Calcite
> Issue Type: Improvement
> Components: server
>Affects Versions: 1.26.0
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
> Labels: pull-request-available
> Time Spent: 4h
> Remaining Estimate: 0h
>
> Presently, the {{ServerDdlExecutor}} incorrectly process some keywords:
> # {{CREATE SCHEMA IF NOT EXISTS}} overwrites the existing schema
> # {{CREATE OR REPLACE TABLE}} doesn't replace the table if the table exists
> The goal of this ticket is to unify the handling of {{IF NOT EXISTS}} and
> {{REPLACE}} keywords for these two commands.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4533) Fix handling of REPLACE and IF NOT EXISTS keywords for CREATE TABLE/SCHEMA commands
[
https://issues.apache.org/jira/browse/CALCITE-4533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17300524#comment-17300524
]
Rui Wang commented on CALCITE-4533:
---
fixed via
https://github.com/apache/calcite/commit/008930a5a0a4310d642ae902365a883208d097cb
thanks [~vozerov]
> Fix handling of REPLACE and IF NOT EXISTS keywords for CREATE TABLE/SCHEMA
> commands
> ---
>
> Key: CALCITE-4533
> URL: https://issues.apache.org/jira/browse/CALCITE-4533
> Project: Calcite
> Issue Type: Improvement
> Components: server
>Affects Versions: 1.26.0
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
> Labels: pull-request-available
> Time Spent: 4h
> Remaining Estimate: 0h
>
> Presently, the {{ServerDdlExecutor}} incorrectly process some keywords:
> # {{CREATE SCHEMA IF NOT EXISTS}} overwrites the existing schema
> # {{CREATE OR REPLACE TABLE}} doesn't replace the table if the table exists
> The goal of this ticket is to unify the handling of {{IF NOT EXISTS}} and
> {{REPLACE}} keywords for these two commands.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4533) Fix handling of REPLACE and IF NOT EXISTS keywords for CREATE TABLE/SCHEMA commands
[
https://issues.apache.org/jira/browse/CALCITE-4533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17299891#comment-17299891
]
Rui Wang commented on CALCITE-4533:
---
So to confirm:
IF NOT EXISTS means do NOT overwrite
CREATE OR REPLACE means can overwrite
?
> Fix handling of REPLACE and IF NOT EXISTS keywords for CREATE TABLE/SCHEMA
> commands
> ---
>
> Key: CALCITE-4533
> URL: https://issues.apache.org/jira/browse/CALCITE-4533
> Project: Calcite
> Issue Type: Improvement
> Components: server
>Affects Versions: 1.26.0
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Presently, the {{ServerDdlExecutor}} incorrectly process some keywords:
> # {{CREATE SCHEMA IF NOT EXISTS}} overwrites the existing schema
> # {{CREATE OR REPLACE TABLE}} doesn't replace the table if the table exists
> The goal of this ticket is to unify the handling of {{IF NOT EXISTS}} and
> {{REPLACE}} keywords for these two commands.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-2317) getFunctions() showing empty
[ https://issues.apache.org/jira/browse/CALCITE-2317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17298512#comment-17298512 ] Rui Wang commented on CALCITE-2317: --- Merged via https://github.com/apache/calcite/commit/e447ff85a0a7d2037b819b7ced91177261974c7e Thanks [~MalteBellmann] for your contribution! > getFunctions() showing empty > > > Key: CALCITE-2317 > URL: https://issues.apache.org/jira/browse/CALCITE-2317 > Project: Calcite > Issue Type: Bug >Reporter: Subbarao >Assignee: Malte Bellmann >Priority: Major > Labels: pull-request-available, pull-requests-available > Attachments: CalciteWithOracle.java > > Time Spent: 1h 40m > Remaining Estimate: 0h > > how to get all function names and procedure names in oracle database using > calcite connection and schema. > schema.getFunctionNames() return result is:[ ] > Then i am try to retrieving DatabaseMetadata.getFunction().Here also it will > be showing empty. > Iam using calciResultSet ,AvaticaResultSet and ResultSet for getting > functions and procedures but will be showing empty. > Is it possible get all function names and procedure names from any database. > But normal jdbc connection using DatabseMetaData properties it retrive alll > function names and procedure names.Why it will not retrive in calcite -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CALCITE-2317) getFunctions() showing empty
[ https://issues.apache.org/jira/browse/CALCITE-2317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rui Wang resolved CALCITE-2317. --- Resolution: Fixed > getFunctions() showing empty > > > Key: CALCITE-2317 > URL: https://issues.apache.org/jira/browse/CALCITE-2317 > Project: Calcite > Issue Type: Bug >Reporter: Subbarao >Assignee: Malte Bellmann >Priority: Major > Labels: pull-request-available, pull-requests-available > Attachments: CalciteWithOracle.java > > Time Spent: 1h 40m > Remaining Estimate: 0h > > how to get all function names and procedure names in oracle database using > calcite connection and schema. > schema.getFunctionNames() return result is:[ ] > Then i am try to retrieving DatabaseMetadata.getFunction().Here also it will > be showing empty. > Iam using calciResultSet ,AvaticaResultSet and ResultSet for getting > functions and procedures but will be showing empty. > Is it possible get all function names and procedure names from any database. > But normal jdbc connection using DatabseMetaData properties it retrive alll > function names and procedure names.Why it will not retrive in calcite -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4426) [CALCITE-4426] Short-circuit evaluating when comparing two "RelTraitSet"s (Jiatao Tao)
[ https://issues.apache.org/jira/browse/CALCITE-4426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17279318#comment-17279318 ] Rui Wang commented on CALCITE-4426: --- merged via https://github.com/apache/calcite/commit/d21d540fafce8225b12b032900a8087f8ac33a91. Thanks [~Aron.tao]! > [CALCITE-4426] Short-circuit evaluating when comparing two "RelTraitSet"s > (Jiatao Tao) > -- > > Key: CALCITE-4426 > URL: https://issues.apache.org/jira/browse/CALCITE-4426 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Major > Labels: pull-request-available > Time Spent: 2h 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CALCITE-4426) [CALCITE-4426] Short-circuit evaluating when comparing two "RelTraitSet"s (Jiatao Tao)
[ https://issues.apache.org/jira/browse/CALCITE-4426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rui Wang resolved CALCITE-4426. --- Fix Version/s: 1.27.0 Resolution: Fixed > [CALCITE-4426] Short-circuit evaluating when comparing two "RelTraitSet"s > (Jiatao Tao) > -- > > Key: CALCITE-4426 > URL: https://issues.apache.org/jira/browse/CALCITE-4426 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Major > Labels: pull-request-available > Fix For: 1.27.0 > > Time Spent: 2h 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-4484) Add UNIQUE_VALUE(x) aggregate function, that throws if x is not unique
[
https://issues.apache.org/jira/browse/CALCITE-4484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17277518#comment-17277518
]
Rui Wang edited comment on CALCITE-4484 at 2/2/21, 11:07 PM:
-
+1 thanks for creating this JIRA [~julianhyde]
was (Author: amaliujia):
+1 thanks for creating this bug [~julianhyde]
> Add UNIQUE_VALUE(x) aggregate function, that throws if x is not unique
> --
>
> Key: CALCITE-4484
> URL: https://issues.apache.org/jira/browse/CALCITE-4484
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Priority: Major
>
> Add a {{UNIQUE_VALUE\(x)}} aggregate function, that throws if {{x}} is not
> unique.
> {{UNIQUE_VALUE\(x)}} would throw if {{x}} has values [1, 2], or has values
> [1, NULL]; but would not throw if x has values [1, 1, 1] or [] or [NULL,
> NULL]. Like {{ANY_VALUE}} it behaves as if {{RESPECT NULLS}} is specified.
> There are similar functions:
> * {{ANY_VALUE\(x)}} non-deterministically picks a value. (It is present in
> BigQuery, MySQL, Snowflake, MSSQL and perhaps others.)
> * {{SINGLE_VALUE\(x)}} returns the value of x if there is just one value
> (e.g. [1] or [NULL]), NULL if there are no values, throws if there is more
> than one value (e.g. [NULL, NULL] or [1, 1, 1] or [1, 2]). {{SINGLE_VALUE}}
> is in Calcite, no other DBs that I am aware of, not documented, but available
> through SQL. Calcite uses it internally to enforce scalar sub-queries.
> BigQuery has an internal function "{{$ANY_AND_CHECK\(x)}}" that is equivalent
> to {{UNIQUE_VALUE\(x)}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4484) Add UNIQUE_VALUE(x) aggregate function, that throws if x is not unique
[
https://issues.apache.org/jira/browse/CALCITE-4484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17277518#comment-17277518
]
Rui Wang commented on CALCITE-4484:
---
+1 thanks for creating this bug [~julianhyde]
> Add UNIQUE_VALUE(x) aggregate function, that throws if x is not unique
> --
>
> Key: CALCITE-4484
> URL: https://issues.apache.org/jira/browse/CALCITE-4484
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Priority: Major
>
> Add a {{UNIQUE_VALUE\(x)}} aggregate function, that throws if {{x}} is not
> unique.
> {{UNIQUE_VALUE\(x)}} would throw if {{x}} has values [1, 2], or has values
> [1, NULL]; but would not throw if x has values [1, 1, 1] or [] or [NULL,
> NULL]. Like {{ANY_VALUE}} it behaves as if {{RESPECT NULLS}} is specified.
> There are similar functions:
> * {{ANY_VALUE\(x)}} non-deterministically picks a value. (It is present in
> BigQuery, MySQL, Snowflake, MSSQL and perhaps others.)
> * {{SINGLE_VALUE\(x)}} returns the value of x if there is just one value
> (e.g. [1] or [NULL]), NULL if there are no values, throws if there is more
> than one value (e.g. [NULL, NULL] or [1, 1, 1] or [1, 2]). {{SINGLE_VALUE}}
> is in Calcite, no other DBs that I am aware of, not documented, but available
> through SQL. Calcite uses it internally to enforce scalar sub-queries.
> BigQuery has an internal function "{{$ANY_AND_CHECK\(x)}}" that is equivalent
> to {{UNIQUE_VALUE\(x)}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CALCITE-4482) "ImmutableBeans.create" has performance issue
[
https://issues.apache.org/jira/browse/CALCITE-4482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rui Wang resolved CALCITE-4482.
---
Fix Version/s: 1.27.0
Resolution: Fixed
> "ImmutableBeans.create" has performance issue
> -
>
> Key: CALCITE-4482
> URL: https://issues.apache.org/jira/browse/CALCITE-4482
> Project: Calcite
> Issue Type: Bug
>Reporter: Jiatao Tao
>Assignee: Jiatao Tao
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.27.0
>
> Attachments: image-2021-02-01-15-42-46-942.png,
> image-2021-02-01-15-45-11-863.png, image-2021-02-01-15-46-08-056.png,
> image-2021-02-01-15-47-31-577.png, image-2021-02-01-20-52-54-892.png
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> We are doing the stressing test, and we found SqlNode#toString's time is
> unusually high, seems the call is all from SqlNode#toString, we can reduce
> the useless call of "ImmutableBeans.create" to reduce the time:
> My proposal is to extra default SqlWriterConfig to SqlNode and
> SqlNode#toString use this static field.
>
> {code:java}
> public static final SqlWriterConfig DEFAULT_SQL_WRITER_CONFIG =
> SqlPrettyWriter.config().withDialect(AnsiSqlDialect.DEFAULT)
> .withAlwaysUseParentheses(false)
> .withSelectListItemsOnSeparateLines(false)
> .withUpdateSetListNewline(false)
> .withIndentation(0);
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4482) "ImmutableBeans.create" has performance issue
[
https://issues.apache.org/jira/browse/CALCITE-4482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17277369#comment-17277369
]
Rui Wang commented on CALCITE-4482:
---
Fixed via
https://github.com/apache/calcite/commit/85f939f922b50aca054e19f21a3c0a55afd4b929.
Thanks [~Aron.tao]!
> "ImmutableBeans.create" has performance issue
> -
>
> Key: CALCITE-4482
> URL: https://issues.apache.org/jira/browse/CALCITE-4482
> Project: Calcite
> Issue Type: Bug
>Reporter: Jiatao Tao
>Assignee: Jiatao Tao
>Priority: Major
> Labels: pull-request-available
> Attachments: image-2021-02-01-15-42-46-942.png,
> image-2021-02-01-15-45-11-863.png, image-2021-02-01-15-46-08-056.png,
> image-2021-02-01-15-47-31-577.png, image-2021-02-01-20-52-54-892.png
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> We are doing the stressing test, and we found SqlNode#toString's time is
> unusually high, seems the call is all from SqlNode#toString, we can reduce
> the useless call of "ImmutableBeans.create" to reduce the time:
> My proposal is to extra default SqlWriterConfig to SqlNode and
> SqlNode#toString use this static field.
>
> {code:java}
> public static final SqlWriterConfig DEFAULT_SQL_WRITER_CONFIG =
> SqlPrettyWriter.config().withDialect(AnsiSqlDialect.DEFAULT)
> .withAlwaysUseParentheses(false)
> .withSelectListItemsOnSeparateLines(false)
> .withUpdateSetListNewline(false)
> .withIndentation(0);
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4483) Add WITHIN DISTINCT clause for aggregate functions
[
https://issues.apache.org/jira/browse/CALCITE-4483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17276926#comment-17276926
]
Rui Wang commented on CALCITE-4483:
---
I am also leaning to SINGLE_VALUE (assuming SINGLE_VALUE means it will throw an
exception when values are not the same).
> Add WITHIN DISTINCT clause for aggregate functions
> --
>
> Key: CALCITE-4483
> URL: https://issues.apache.org/jira/browse/CALCITE-4483
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Add a {{WITHIN DISTINCT}} clause to aggregate functions, allowing duplicate
> rows to be eliminated before entering the function.
> This feature is non-standard, and in fact does not exist in any database I am
> aware of.
> It is related to {{DISTINCT}}, and is in fact a generalization of it.
> {{DISTINCT}} can always be rewritten in terms of {{WITHIN DISTINCT}}. For
> example, {{SUM(DISTINCT sal)}} is equivalent to {{SUM(sal) WITHIN DISTINCT
> (sal)}}.
> Consider the query
> {noformat}
> SELECT SUM(age),
>SUM(DISTINCT age),
> SUM(age) WITHIN DISTINCT (name)
> FROM Friends{noformat}
> where {{Friends}} has the rows
> {noformat}
> name age job
> == === ==
> Julian 16 Programmer
> Dick15
> Anne13 Car wash
> George 15 Lifeguard
> George 15 Dog walker
> Timmy4
> {noformat}
> Note that there are two rows for George, because she has two jobs.
> The values of the columns are as follows:
> * {{SUM(age)}} has the value (16 + 15 + 13 + 15 + 15 + 4) = 78;
> * {{SUM(DISTINCT age)}} has the value (16 + 15 + 13 + 4) = 48;
> * {{SUM(age) WITHIN DISTINCT (name)}} has the value (16 + 15 + 13 + 15 + 4)
> = 63.
> {{WITHIN DISTINCT}} has treated the two 15 values for George as one value,
> but has still counted the 15 for Dick separately.
> The {{WITHIN DISTINCT}} clause can be useful to prevent double-counting when
> duplicates have been added via a many-to-one join.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4482) "ImmutableBeans.create" has performance issue
[
https://issues.apache.org/jira/browse/CALCITE-4482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17276606#comment-17276606
]
Rui Wang commented on CALCITE-4482:
---
The fix in SqlPrettyWriter seems good.
Also get rid of nameMap by not calling SqlNode.toString() makes sense. I agree
that can be addressed by another JIRA
> "ImmutableBeans.create" has performance issue
> -
>
> Key: CALCITE-4482
> URL: https://issues.apache.org/jira/browse/CALCITE-4482
> Project: Calcite
> Issue Type: Bug
>Reporter: Jiatao Tao
>Assignee: Jiatao Tao
>Priority: Major
> Attachments: image-2021-02-01-15-42-46-942.png,
> image-2021-02-01-15-45-11-863.png, image-2021-02-01-15-46-08-056.png,
> image-2021-02-01-15-47-31-577.png, image-2021-02-01-20-52-54-892.png
>
>
> We are doing the stressing test, and we found SqlNode#toString's time is
> unusually high, seems the call is all from SqlNode#toString, we can reduce
> the useless call of "ImmutableBeans.create" to reduce the time:
> My proposal is to extra default SqlWriterConfig to SqlNode and
> SqlNode#toString use this static field.
>
> {code:java}
> public static final SqlWriterConfig DEFAULT_SQL_WRITER_CONFIG =
> SqlPrettyWriter.config().withDialect(AnsiSqlDialect.DEFAULT)
> .withAlwaysUseParentheses(false)
> .withSelectListItemsOnSeparateLines(false)
> .withUpdateSetListNewline(false)
> .withIndentation(0);
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4483) Add WITHIN DISTINCT clause for aggregate functions
[
https://issues.apache.org/jira/browse/CALCITE-4483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17276604#comment-17276604
]
Rui Wang commented on CALCITE-4483:
---
Use the example above, I guess there is an ambiguity to me:
SUM(age) WITHIN DISTINCT (name)
Which age to use for the same name, especially when for the same name, multiple
ages are different? (the age is happen to be the same in this example, but
that's no guarantee).
> Add WITHIN DISTINCT clause for aggregate functions
> --
>
> Key: CALCITE-4483
> URL: https://issues.apache.org/jira/browse/CALCITE-4483
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Priority: Major
>
> Add a {{WITHIN DISTINCT}} clause to aggregate functions, allowing duplicate
> rows to be eliminated before entering the function.
> This feature is non-standard, and in fact does not exist in any database I am
> aware of.
> It is related to {{DISTINCT}}, and is in fact a generalization of it.
> {{DISTINCT}} can always be rewritten in terms of {{WITHIN DISTINCT}}. For
> example, {{SUM(DISTINCT sal)}} is equivalent to {{SUM(sal) WITHIN DISTINCT
> (sal)}}.
> Consider the query
> {noformat}
> SELECT SUM(age),
>SUM(DISTINCT age),
> SUM(age) WITHIN DISTINCT (name)
> FROM Friends{noformat}
> where {{Friends}} has the rows
> {noformat}
> name age job
> == === ==
> Julian 16 Programmer
> Dick15
> Anne13 Car wash
> George 15 Lifeguard
> George 15 Dog walker
> Timmy4
> {noformat}
> Note that there are two rows for George, because she has two jobs.
> The values of the columns are as follows:
> * {{SUM(age)}} has the value (16 + 15 + 13 + 15 + 15 + 4) = 78;
> * {{SUM(DISTINCT age)}} has the value (16 + 15 + 13 + 4) = 48;
> * {{SUM(age) WITHIN DISTINCT (name)}} has the value (16 + 15 + 13 + 15 + 4)
> = 63.
> {{WITHIN DISTINCT}} has treated the two 15 values for George as one value,
> but has still counted the 15 for Dick separately.
> The {{WITHIN DISTINCT}} clause can be useful to prevent double-counting when
> duplicates have been added via a many-to-one join.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4461) Do not cast to logical node inside Enumerable rules
[
https://issues.apache.org/jira/browse/CALCITE-4461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17276063#comment-17276063
]
Rui Wang commented on CALCITE-4461:
---
merged via
https://github.com/apache/calcite/commit/1bf6b08a81f471f979e1b52174f225f03ff77a2e!
> Do not cast to logical node inside Enumerable rules
> ---
>
> Key: CALCITE-4461
> URL: https://issues.apache.org/jira/browse/CALCITE-4461
> Project: Calcite
> Issue Type: Task
> Components: core
>Affects Versions: 1.26.0
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.27.0
>
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> Currently, some {{Enumerable}} rules work with the base operator classes,
> such as {{Join}}, while others have an explicit cast to {{Logical}}
> counterparts, such as `LogicalJoin`, {{LogicalProject}}, etc. This makes it
> impossible to convert custom non-logical nodes into {{Enumerable}} using the
> built-in rules because such an invocation will fail with a
> {{ClassCastException}}.
> The proposal is to change all existing rules so that they work with the base
> {{RelNode}} classes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CALCITE-4461) Do not cast to logical node inside Enumerable rules
[
https://issues.apache.org/jira/browse/CALCITE-4461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rui Wang resolved CALCITE-4461.
---
Resolution: Fixed
> Do not cast to logical node inside Enumerable rules
> ---
>
> Key: CALCITE-4461
> URL: https://issues.apache.org/jira/browse/CALCITE-4461
> Project: Calcite
> Issue Type: Task
> Components: core
>Affects Versions: 1.26.0
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.27.0
>
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> Currently, some {{Enumerable}} rules work with the base operator classes,
> such as {{Join}}, while others have an explicit cast to {{Logical}}
> counterparts, such as `LogicalJoin`, {{LogicalProject}}, etc. This makes it
> impossible to convert custom non-logical nodes into {{Enumerable}} using the
> built-in rules because such an invocation will fail with a
> {{ClassCastException}}.
> The proposal is to change all existing rules so that they work with the base
> {{RelNode}} classes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4481) Replace some self-define methods with jdk methods in order to improve the readability
[ https://issues.apache.org/jira/browse/CALCITE-4481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17275261#comment-17275261 ] Rui Wang commented on CALCITE-4481: --- If there are equivalent methods in JDK we can certainly use those. Please feel free to create PR in this case so we can see what can be replaced. > Replace some self-define methods with jdk methods in order to improve the > readability > - > > Key: CALCITE-4481 > URL: https://issues.apache.org/jira/browse/CALCITE-4481 > Project: Calcite > Issue Type: Improvement >Reporter: dugenkui >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3221) Add a sort-merge union algorithm
[ https://issues.apache.org/jira/browse/CALCITE-3221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17273114#comment-17273114 ] Rui Wang commented on CALCITE-3221: --- I am thinking the valid conversion for select * from (select x from r union all select x from s) order by x offset 100 limit 10 is select * from (select x from r order by x limit 110 union all select x from s order by x limit 110) order by x offset 100 limit 10 > Add a sort-merge union algorithm > > > Key: CALCITE-3221 > URL: https://issues.apache.org/jira/browse/CALCITE-3221 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.19.0 >Reporter: Stamatis Zampetakis >Assignee: Ruben Q L >Priority: Minor > Labels: pull-request-available > Attachments: screenshot-1.png > > Time Spent: 12h > Remaining Estimate: 0h > > Currently, the union operation offered by Calcite (see > [EnumerableDefaults.union|https://github.com/apache/calcite/blob/d98856bf1a5f5c151d004b769e14bdd368a67234/linq4j/src/main/java/org/apache/calcite/linq4j/EnumerableDefaults.java#L2747]) > "breaks" the collation (if any) of its inputs. > The goal of this issue is to create a new union algorithm > (EnumerableMergeUnion) that, given the fact that its inputs are sorted by the > same collation, will return the union / union all result respecting this > collation. > Most likely the implementation of the merge join can be useful. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CALCITE-4474) SqlSimpleParser inner Tokenizer should not recognize the sql of TokenType.ID or some keywords in some case
[
https://issues.apache.org/jira/browse/CALCITE-4474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rui Wang resolved CALCITE-4474.
---
Resolution: Fixed
> SqlSimpleParser inner Tokenizer should not recognize the sql of TokenType.ID
> or some keywords in some case
> --
>
> Key: CALCITE-4474
> URL: https://issues.apache.org/jira/browse/CALCITE-4474
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.26.0
>Reporter: wangjie
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.26.0
>
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> in SqlSimpleParser.Tokenizer#nextToken() lines 401 - 423, is used to
> recognize the sql of TokenType.ID or some keywords.
> If a certain segment of characters is continuously composed of Token,the
> function of this code may be wrong.
>
> E.g :
> (1)select * from a where price> 10.0\-–comment
> 【10.0\-–comment】should be recognize as TokenType.ID("10.0") and
> TokenType.COMMENT, but it recognize as TokenType.ID("10.0--comment")
> (2)select * from a where column_b='/* this is not comment */'
> 【/\* this is not comment \*/】should be recognize as TokenType.SQID("/\* this
> is not comment \*/"), but it was not
>
> you can see reproduce-demo in
> [https://github.com/wangjie-fourth/calcite-reproduce]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4474) SqlSimpleParser inner Tokenizer should not recognize the sql of TokenType.ID or some keywords in some case
[
https://issues.apache.org/jira/browse/CALCITE-4474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17271784#comment-17271784
]
Rui Wang commented on CALCITE-4474:
---
[~wangjie_fourth]
fixed via
https://github.com/apache/calcite/commit/a16a47351aa25caf538c1955edd171ec871569f7.
Thanks for your contribution!
> SqlSimpleParser inner Tokenizer should not recognize the sql of TokenType.ID
> or some keywords in some case
> --
>
> Key: CALCITE-4474
> URL: https://issues.apache.org/jira/browse/CALCITE-4474
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.26.0
>Reporter: wangjie
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.26.0
>
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> in SqlSimpleParser.Tokenizer#nextToken() lines 401 - 423, is used to
> recognize the sql of TokenType.ID or some keywords.
> If a certain segment of characters is continuously composed of Token,the
> function of this code may be wrong.
>
> E.g :
> (1)select * from a where price> 10.0\-–comment
> 【10.0\-–comment】should be recognize as TokenType.ID("10.0") and
> TokenType.COMMENT, but it recognize as TokenType.ID("10.0--comment")
> (2)select * from a where column_b='/* this is not comment */'
> 【/\* this is not comment \*/】should be recognize as TokenType.SQID("/\* this
> is not comment \*/"), but it was not
>
> you can see reproduce-demo in
> [https://github.com/wangjie-fourth/calcite-reproduce]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4466) Do not RelTraitDef.convert if the "from" trait already satisfies the "to" trait.
[
https://issues.apache.org/jira/browse/CALCITE-4466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17269788#comment-17269788
]
Rui Wang commented on CALCITE-4466:
---
Merged via https://github.com/apache/calcite/commit/2ee4d. Thanks [~vozerov]
for your contribution!
> Do not RelTraitDef.convert if the "from" trait already satisfies the "to"
> trait.
>
>
> Key: CALCITE-4466
> URL: https://issues.apache.org/jira/browse/CALCITE-4466
> Project: Calcite
> Issue Type: Task
> Components: core
>Affects Versions: 1.26.0
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.27.0
>
> Time Spent: 3h
> Remaining Estimate: 0h
>
> Consider that we have two trait defs {{A_def}} and {{B_def}}. We have a node
> with the trait set {{[A_from, B_from]}} that we want to convert to a node
> with the traits set {{[A_to, B_to]}}. Suppose that:
> * {{A_from.satisfies(A_to) = false}}
> * {{B_from.satisfies(B_to) = true}}
> Currently, the {{VolcanoPlanner}} will invoke {{convert}} on both {{A_trait}}
> and {{B_trait}}, because it skips the conversion only when two traits are
> *equal*. In our example, it will lead to an unnecessary call to
> {{B_def.convert(node, B_to)}}. This is not a big problem but it forces
> implementors of custom traits to double-check whether the passed node already
> satisfies the required trait or not.
> The proposal is to replace {{fromTrait.equals(toTrait)}} with
> {{fromTrait.satisfies(toTrait)}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CALCITE-4466) Do not RelTraitDef.convert if the "from" trait already satisfies the "to" trait.
[
https://issues.apache.org/jira/browse/CALCITE-4466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rui Wang resolved CALCITE-4466.
---
Resolution: Fixed
> Do not RelTraitDef.convert if the "from" trait already satisfies the "to"
> trait.
>
>
> Key: CALCITE-4466
> URL: https://issues.apache.org/jira/browse/CALCITE-4466
> Project: Calcite
> Issue Type: Task
> Components: core
>Affects Versions: 1.26.0
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.27.0
>
> Time Spent: 3h
> Remaining Estimate: 0h
>
> Consider that we have two trait defs {{A_def}} and {{B_def}}. We have a node
> with the trait set {{[A_from, B_from]}} that we want to convert to a node
> with the traits set {{[A_to, B_to]}}. Suppose that:
> * {{A_from.satisfies(A_to) = false}}
> * {{B_from.satisfies(B_to) = true}}
> Currently, the {{VolcanoPlanner}} will invoke {{convert}} on both {{A_trait}}
> and {{B_trait}}, because it skips the conversion only when two traits are
> *equal*. In our example, it will lead to an unnecessary call to
> {{B_def.convert(node, B_to)}}. This is not a big problem but it forces
> implementors of custom traits to double-check whether the passed node already
> satisfies the required trait or not.
> The proposal is to replace {{fromTrait.equals(toTrait)}} with
> {{fromTrait.satisfies(toTrait)}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3221) Add a sort-merge union algorithm
[
https://issues.apache.org/jira/browse/CALCITE-3221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17267578#comment-17267578
]
Rui Wang commented on CALCITE-3221:
---
Thanks [~rubenql]
Will try to give reviews on your PR.
> Add a sort-merge union algorithm
>
>
> Key: CALCITE-3221
> URL: https://issues.apache.org/jira/browse/CALCITE-3221
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.19.0
>Reporter: Stamatis Zampetakis
>Assignee: Ruben Q L
>Priority: Minor
> Labels: pull-request-available
> Attachments: screenshot-1.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently, the union operation offered by Calcite is based on a {{HashSet}}
> (see
> [EnumerableDefaults.union|https://github.com/apache/calcite/blob/d98856bf1a5f5c151d004b769e14bdd368a67234/linq4j/src/main/java/org/apache/calcite/linq4j/EnumerableDefaults.java#L2747])
> and necessitates reading in memory all rows before returning a single
> result.
> Apart from increased memory consumption the operator is blocking and also
> destroys the order of its inputs.
> The goal of this issue is to add a new union algorithm (EnumerableMergeUnion
> ?) exploiting the fact that the inputs are sorted which consumes less memory
> and retains the order of its inputs.
> Most likely the implementation of the merge join can be useful.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4466) Do not RelTraitDef.convert if the "from" trait already satisfies the "to" trait.
[
https://issues.apache.org/jira/browse/CALCITE-4466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265126#comment-17265126
]
Rui Wang commented on CALCITE-4466:
---
+1
I think it makes senses. At least based on the javadoc, satisfies() returns
true means equal or stricter, which is better to use only equal.
Will give a review on the PR.
> Do not RelTraitDef.convert if the "from" trait already satisfies the "to"
> trait.
>
>
> Key: CALCITE-4466
> URL: https://issues.apache.org/jira/browse/CALCITE-4466
> Project: Calcite
> Issue Type: Task
> Components: core
>Affects Versions: 1.26.0
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.27.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Consider that we have two trait defs {{A_def}} and {{B_def}}. We have a node
> with the trait set {{[A_from, B_from]}} that we want to convert to a node
> with the traits set {{[A_to, B_to]}}. Suppose that:
> * {{A_from.satisfies(A_to) = false}}
> * {{B_from.satisfies(B_to) = true}}
> Currently, the {{VolcanoPlanner}} will invoke {{convert}} on both {{A_trait}}
> and {{B_trait}}, because it skips the conversion only when two traits are
> *equal*. In our example, it will lead to an unnecessary call to
> {{B_def.convert(node, B_to)}}. This is not a big problem but it forces
> implementors of custom traits to double-check whether the passed node already
> satisfies the required trait or not.
> The proposal is to replace {{fromTrait.equals(toTrait)}} with
> {{fromTrait.satisfies(toTrait)}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4458) The "rowTypeCoercion" for "SET" operations should be "or" relationship
[
https://issues.apache.org/jira/browse/CALCITE-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17263792#comment-17263792
]
Rui Wang commented on CALCITE-4458:
---
+1
[~Aron.tao] Can you give an concrete example for this JIRA, especially that
sounds like it is hard to come up with a new UT in the PR.
> The "rowTypeCoercion" for "SET" operations should be "or" relationship
> --
>
> Key: CALCITE-4458
> URL: https://issues.apache.org/jira/browse/CALCITE-4458
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Jiatao Tao
>Assignee: Jiatao Tao
>Priority: Critical
> Labels: pull-request-available
> Time Spent: 50m
> Remaining Estimate: 0h
>
> In
> org.apache.calcite.sql.validate.implicit.TypeCoercionImpl#rowTypeCoercion#124:
> {code:java}
> case UNION:
> case INTERSECT:
> case EXCEPT:
> // Set operations are binary for now.
> final SqlCall operand0 = ((SqlCall) query).operand(0);
> final SqlCall operand1 = ((SqlCall) query).operand(1);
> final boolean coerced = rowTypeCoercion(scope, operand0, columnIndex,
> targetType)
> && rowTypeCoercion(scope, operand1, columnIndex, targetType);
> {code}
> Seems the coerced should be "||", not "&&"
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4463) why doesn't dialect.unparseOffsetFetch method apply to SqlOrderBy tree node
[
https://issues.apache.org/jira/browse/CALCITE-4463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17263646#comment-17263646
]
Rui Wang commented on CALCITE-4463:
---
As Julian suggested, maybe just change your title from a question to a
statement, and then probably come up with a single test to verify whether the
statement is true.
> why doesn't dialect.unparseOffsetFetch method apply to SqlOrderBy tree node
> ---
>
> Key: CALCITE-4463
> URL: https://issues.apache.org/jira/browse/CALCITE-4463
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.26.0
> Environment: jvm: open-jdk8
>
> calcite: 1.26.0
>Reporter: yanjing.wang
>Priority: Major
> Attachments: image-2021-01-12-10-06-29-813.png
>
>
> in SqlOrderBy$Operator class, the unparse method code offset and fetch hardly
> and close the door to transform my sql to limit x offset y style.
> why doesn't it invoke dialect.unparseOffsetFetch like SqlSelectOperator?
>
> !image-2021-01-12-10-06-29-813.png!
>
> my unparse sql code:
> {code:java}
> String sql = "select concat(a.id,'-',b.id) , a.name from xxx.bb limit 5";
> SqlDialect SPARK = new
> SparkSqlDialect(SqlDialect.EMPTY_CONTEXT
> .withDatabaseProduct(SqlDialect.DatabaseProduct.SPARK)
> .withIdentifierQuoteString("`").withNullCollation(NullCollation.LOW)
> .withLiteralQuoteString("'").withLiteralEscapedQuoteString("''")
>
> .withUnquotedCasing(Casing.UNCHANGED).withQuotedCasing(Casing.UNCHANGED));
> SqlParser.Config configBuilder =
> SqlParser.config()
> .withParserFactory(SqlBabelParserImpl.FACTORY)
> .withConformance(SqlConformanceEnum.LENIENT);
> SqlParser sqlParser = SqlParser.create(sql, configBuilder);
> try {
> SqlNode sqlNode = sqlParser.parseQuery();
> SqlString sqlString = sqlNode.toSqlString(SPARK);
> System.out.println(sqlString);
> } catch (SqlParseException e) {
> e.printStackTrace();
> }{code}
> result:
> {code:java}
> SELECT `CONCAT`(`A`.`ID`, '-', `B`.`ID`), `A`.`NAME` FROM `XXX`.`BB` FETCH
> NEXT 5 ROWS ONLY
> {code}
> what should i do if i want transform some other dialect sql to spark, because
> spark doesn't support "FETCH NEXT 5000 ROWS ONLY"
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4465) Estimate the number of distinct values by filter condition
[
https://issues.apache.org/jira/browse/CALCITE-4465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17263645#comment-17263645
]
Rui Wang commented on CALCITE-4465:
---
+1 this idea make senses to me! Will be happy to help review if you have a PR
later.
> Estimate the number of distinct values by filter condition
> --
>
> Key: CALCITE-4465
> URL: https://issues.apache.org/jira/browse/CALCITE-4465
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Liya Fan
>Assignee: Liya Fan
>Priority: Major
>
> According to our current implementation ({{RelMdDistinctRowCount}}),
> estimating the number of distinctive values (NDV) does not make good use of
> the filter condition. It simply forwards the call to its input operator with
> the fiter condition attached.
> In fact, more information can be obtained for some special but commonly used
> conditions. For example, given condition {{x = 'a'}}, we can deduce that
> {{NDV( x ) <= 1}}. Given condition {{x in ('a', 'b')}}, we can deduce that
> {{NDV( x ) <= 2}}.
> More generally, if we have {{x in ('a', 'b') AND y in ('c', 'd', 'e')}}, we
> have {{NDV(x, y) <= 2 * 3 = 6}}.
> Thoughts?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CALCITE-4450) ElasticSearch query with varchar literal projection fails with JsonParseException
[
https://issues.apache.org/jira/browse/CALCITE-4450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rui Wang resolved CALCITE-4450.
---
Resolution: Fixed
> ElasticSearch query with varchar literal projection fails with
> JsonParseException
> -
>
> Key: CALCITE-4450
> URL: https://issues.apache.org/jira/browse/CALCITE-4450
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.26.0
>Reporter: Vova Vysotskyi
>Assignee: Vova Vysotskyi
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.27.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> A query that contains varchar literals in projection fails for ElasticSearch
> adapter. Simple test case to reproduce the issue:
> {code:java}
> @Test void projectionStringLiteral() {
> CalciteAssert.that()
> .with(newConnectionFactory())
> .query(
> String.format(Locale.ROOT, "select 'foo' as \"lit\"\n"
> + "from \"elastic\".\"%s\"", NAME))
> .returns("lit=foo\n");
> }
> {code}
> Error:
> {noformat}
> Caused by: com.fasterxml.jackson.core.JsonParseException: Unexpected
> character ('f' (code 102)): was expecting comma to separate Object entries
> at [Source: (String)"{"script_fields": {"lit":{"script": ""foo""},
> "a":{"script": "params._source.a"}}}"; line: 1, column: 40]
> at
> com.fasterxml.jackson.core.JsonParser._constructError(JsonParser.java:1840)
> {noformat}
> The problem is that {{RexToElasticsearchTranslator.visitLiteral}} method do
> not escape literal quotes, and forms the following string: {{"lit":""foo""}}
> that cannot be handled by jackson.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4450) ElasticSearch query with varchar literal projection fails with JsonParseException
[
https://issues.apache.org/jira/browse/CALCITE-4450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17260070#comment-17260070
]
Rui Wang commented on CALCITE-4450:
---
Fixed in
https://github.com/apache/calcite/commit/be649b52eabb33d7252a146c50b769d271241dcd
[~volodymyr] thanks!
> ElasticSearch query with varchar literal projection fails with
> JsonParseException
> -
>
> Key: CALCITE-4450
> URL: https://issues.apache.org/jira/browse/CALCITE-4450
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.26.0
>Reporter: Vova Vysotskyi
>Assignee: Vova Vysotskyi
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.27.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> A query that contains varchar literals in projection fails for ElasticSearch
> adapter. Simple test case to reproduce the issue:
> {code:java}
> @Test void projectionStringLiteral() {
> CalciteAssert.that()
> .with(newConnectionFactory())
> .query(
> String.format(Locale.ROOT, "select 'foo' as \"lit\"\n"
> + "from \"elastic\".\"%s\"", NAME))
> .returns("lit=foo\n");
> }
> {code}
> Error:
> {noformat}
> Caused by: com.fasterxml.jackson.core.JsonParseException: Unexpected
> character ('f' (code 102)): was expecting comma to separate Object entries
> at [Source: (String)"{"script_fields": {"lit":{"script": ""foo""},
> "a":{"script": "params._source.a"}}}"; line: 1, column: 40]
> at
> com.fasterxml.jackson.core.JsonParser._constructError(JsonParser.java:1840)
> {noformat}
> The problem is that {{RexToElasticsearchTranslator.visitLiteral}} method do
> not escape literal quotes, and forms the following string: {{"lit":""foo""}}
> that cannot be handled by jackson.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4434) Cannot implement 'CASE row WHEN row ...'
[
https://issues.apache.org/jira/browse/CALCITE-4434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17259270#comment-17259270
]
Rui Wang commented on CALCITE-4434:
---
Sorry I just came back from vocation.
Thanks [~zhenw] for your contribution!
Thanks [~julianhyde] for helping merging the commit!
> Cannot implement 'CASE row WHEN row ...'
>
>
> Key: CALCITE-4434
> URL: https://issues.apache.org/jira/browse/CALCITE-4434
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Zhen Wang
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.27.0
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Cannot implement 'CASE row WHEN row ...'.
> For example, the test
> {noformat}
> diff --git a/core/src/test/resources/sql/misc.iq
> b/core/src/test/resources/sql/misc.iq
> index 3c945e2cc..84ef67b6c 100644
> --- a/core/src/test/resources/sql/misc.iq
> +++ b/core/src/test/resources/sql/misc.iq
> @@ -1065,6 +1065,47 @@ Expression 'DEPTNO' is not being grouped
>
> !use scott
>
> +# [CALCITE-] Cannot implement 'CASE row WHEN row ...'
> +SELECT deptno, job,
> + CASE (deptno, job)
> + WHEN (20, 'CLERK') THEN 1
> + WHEN (30, 'SALESMAN') THEN 2
> + ELSE 3
> + END AS x
> +FROM "scott".emp
> +WHERE empno < 7600;
> +++--+---+
> +| DEPTNO | JOB | X |
> +++--+---+
> +| 20 | CLERK| 1 |
> +| 20 | MANAGER | 3 |
> +| 30 | SALESMAN | 2 |
> +| 30 | SALESMAN | 2 |
> +++--+---+
> +(4 rows)
> +!ok
> +
> +# Equivalent to previous
> +SELECT deptno, job,
> + CASE
> + WHEN deptno = 20 AND job = 'CLERK' THEN 1
> + WHEN deptno = 30 AND job = 'SALESMAN' THEN 2
> + ELSE 3
> + END AS x
> +FROM "scott".emp
> +WHERE empno < 7600;
> +++--+---+
> +| DEPTNO | JOB | X |
> +++--+---+
> +| 20 | CLERK| 1 |
> +| 20 | MANAGER | 3 |
> +| 30 | SALESMAN | 2 |
> +| 30 | SALESMAN | 2 |
> +++--+---+
> +(4 rows)
> +
> +!ok
> +
> {noformat}
> fails with the following stack trace:
> {noformat}
> Unable to implement EnumerableCalc(expr#0..7=[{inputs}], expr#8=[ROW($t7,
> $t2)], expr#9=[CAST($t8):RecordType(INTEGER EXPR$0, VARCHAR(9) EXPR$1) NOT
> NULL], expr#10=[20], expr#11=['CLERK'], expr#12=[ROW($t10, $t11)],
> expr#13=[CAST($t12):RecordType(INTEGER EXPR$0, VARCHAR(9) EXPR$1) NOT NULL],
> expr#14=[=($t9, $t13)], expr#15=[1], expr#16=[30], expr#17=['SALESMAN'],
> expr#18=[ROW($t16, $t17)], expr#19=[CAST($t18):RecordType(INTEGER EXPR$0,
> VARCHAR(9) EXPR$1) NOT NULL], expr#20=[=($t9, $t19)], expr#21=[2],
> expr#22=[3], expr#23=[CASE($t14, $t15, $t20, $t21, $t22)], expr#24=[7600],
> expr#25=[<($t0, $t24)], DEPTNO=[$t7], JOB=[$t2], X=[$t23],
> $condition=[$t25]): rowcount = 7.0, cumulative cost = {21.0 rows, 435.0 cpu,
> 0.0 io}, id = 49495
> EnumerableTableScan(table=[[scott, EMP]]): rowcount = 14.0, cumulative cost
> = {14.0 rows, 15.0 cpu, 0.0 io}, id = 49458
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:163)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:227)
> at net.hydromatic.quidem.Quidem.checkResult(Quidem.java:322)
> ...
> Caused by: java.lang.IllegalStateException: Unable to implement
> EnumerableCalc(expr#0..7=[{inputs}], expr#8=[ROW($t7, $t2)],
> expr#9=[CAST($t8):RecordType(INTEGER EXPR$0, VARCHAR(9) EXPR$1) NOT NULL],
> expr#10=[20], expr#11=['CLERK'], expr#12=[ROW($t10, $t11)],
> expr#13=[CAST($t12):RecordType(INTEGER EXPR$0, VARCHAR(9) EXPR$1) NOT NULL],
> expr#14=[=($t9, $t13)], expr#15=[1], expr#16=[30], expr#17=['SALESMAN'],
> expr#18=[ROW($t16, $t17)], expr#19=[CAST($t18):RecordType(INTEGER EXPR$0,
> VARCHAR(9) EXPR$1) NOT NULL], expr#20=[=($t9, $t19)], expr#21=[2],
> expr#22=[3], expr#23=[CASE($t14, $t15, $t20, $t21, $t22)], expr#24=[7600],
> expr#25=[<($t0, $t24)], DEPTNO=[$t7], JOB=[$t2], X=[$t23],
> $condition=[$t25]): rowcount = 7.0, cumulative cost = {21.0 rows, 435.0 cpu,
> 0.0 io}, id = 49495
> EnumerableTableScan(table=[[scott, EMP]]): rowcount = 14.0, cumulative cost
> = {14.0 rows, 15.0 cpu, 0.0 io}, id = 49458
> at
> org.apache.calcite.adapter.enumerable.EnumerableRelImplementor.implementRoot(EnumerableRelImplementor.java:114)
> at
> org.apache.calcite.adapter.enumerable.EnumerableInterpretable.toBindable(EnumerableInterpretable.java:113)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl$CalcitePreparingStmt.implement(CalcitePrepareImpl.java:1130)
> ...
> Suppressed: java.lang.NullPointerException: SqlTypeFamily
[jira] [Commented] (CALCITE-4434) Cannot implement 'CASE row WHEN row ...'
[
https://issues.apache.org/jira/browse/CALCITE-4434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17256849#comment-17256849
]
Rui Wang commented on CALCITE-4434:
---
[~julianhyde]
Thanks for your suggestions. I probably should find a better way for me to
merge commits :).
> Cannot implement 'CASE row WHEN row ...'
>
>
> Key: CALCITE-4434
> URL: https://issues.apache.org/jira/browse/CALCITE-4434
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Zhen Wang
>Priority: Major
> Labels: pull-request-available
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Cannot implement 'CASE row WHEN row ...'.
> For example, the test
> {noformat}
> diff --git a/core/src/test/resources/sql/misc.iq
> b/core/src/test/resources/sql/misc.iq
> index 3c945e2cc..84ef67b6c 100644
> --- a/core/src/test/resources/sql/misc.iq
> +++ b/core/src/test/resources/sql/misc.iq
> @@ -1065,6 +1065,47 @@ Expression 'DEPTNO' is not being grouped
>
> !use scott
>
> +# [CALCITE-] Cannot implement 'CASE row WHEN row ...'
> +SELECT deptno, job,
> + CASE (deptno, job)
> + WHEN (20, 'CLERK') THEN 1
> + WHEN (30, 'SALESMAN') THEN 2
> + ELSE 3
> + END AS x
> +FROM "scott".emp
> +WHERE empno < 7600;
> +++--+---+
> +| DEPTNO | JOB | X |
> +++--+---+
> +| 20 | CLERK| 1 |
> +| 20 | MANAGER | 3 |
> +| 30 | SALESMAN | 2 |
> +| 30 | SALESMAN | 2 |
> +++--+---+
> +(4 rows)
> +!ok
> +
> +# Equivalent to previous
> +SELECT deptno, job,
> + CASE
> + WHEN deptno = 20 AND job = 'CLERK' THEN 1
> + WHEN deptno = 30 AND job = 'SALESMAN' THEN 2
> + ELSE 3
> + END AS x
> +FROM "scott".emp
> +WHERE empno < 7600;
> +++--+---+
> +| DEPTNO | JOB | X |
> +++--+---+
> +| 20 | CLERK| 1 |
> +| 20 | MANAGER | 3 |
> +| 30 | SALESMAN | 2 |
> +| 30 | SALESMAN | 2 |
> +++--+---+
> +(4 rows)
> +
> +!ok
> +
> {noformat}
> fails with the following stack trace:
> {noformat}
> Unable to implement EnumerableCalc(expr#0..7=[{inputs}], expr#8=[ROW($t7,
> $t2)], expr#9=[CAST($t8):RecordType(INTEGER EXPR$0, VARCHAR(9) EXPR$1) NOT
> NULL], expr#10=[20], expr#11=['CLERK'], expr#12=[ROW($t10, $t11)],
> expr#13=[CAST($t12):RecordType(INTEGER EXPR$0, VARCHAR(9) EXPR$1) NOT NULL],
> expr#14=[=($t9, $t13)], expr#15=[1], expr#16=[30], expr#17=['SALESMAN'],
> expr#18=[ROW($t16, $t17)], expr#19=[CAST($t18):RecordType(INTEGER EXPR$0,
> VARCHAR(9) EXPR$1) NOT NULL], expr#20=[=($t9, $t19)], expr#21=[2],
> expr#22=[3], expr#23=[CASE($t14, $t15, $t20, $t21, $t22)], expr#24=[7600],
> expr#25=[<($t0, $t24)], DEPTNO=[$t7], JOB=[$t2], X=[$t23],
> $condition=[$t25]): rowcount = 7.0, cumulative cost = {21.0 rows, 435.0 cpu,
> 0.0 io}, id = 49495
> EnumerableTableScan(table=[[scott, EMP]]): rowcount = 14.0, cumulative cost
> = {14.0 rows, 15.0 cpu, 0.0 io}, id = 49458
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:163)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:227)
> at net.hydromatic.quidem.Quidem.checkResult(Quidem.java:322)
> ...
> Caused by: java.lang.IllegalStateException: Unable to implement
> EnumerableCalc(expr#0..7=[{inputs}], expr#8=[ROW($t7, $t2)],
> expr#9=[CAST($t8):RecordType(INTEGER EXPR$0, VARCHAR(9) EXPR$1) NOT NULL],
> expr#10=[20], expr#11=['CLERK'], expr#12=[ROW($t10, $t11)],
> expr#13=[CAST($t12):RecordType(INTEGER EXPR$0, VARCHAR(9) EXPR$1) NOT NULL],
> expr#14=[=($t9, $t13)], expr#15=[1], expr#16=[30], expr#17=['SALESMAN'],
> expr#18=[ROW($t16, $t17)], expr#19=[CAST($t18):RecordType(INTEGER EXPR$0,
> VARCHAR(9) EXPR$1) NOT NULL], expr#20=[=($t9, $t19)], expr#21=[2],
> expr#22=[3], expr#23=[CASE($t14, $t15, $t20, $t21, $t22)], expr#24=[7600],
> expr#25=[<($t0, $t24)], DEPTNO=[$t7], JOB=[$t2], X=[$t23],
> $condition=[$t25]): rowcount = 7.0, cumulative cost = {21.0 rows, 435.0 cpu,
> 0.0 io}, id = 49495
> EnumerableTableScan(table=[[scott, EMP]]): rowcount = 14.0, cumulative cost
> = {14.0 rows, 15.0 cpu, 0.0 io}, id = 49458
> at
> org.apache.calcite.adapter.enumerable.EnumerableRelImplementor.implementRoot(EnumerableRelImplementor.java:114)
> at
> org.apache.calcite.adapter.enumerable.EnumerableInterpretable.toBindable(EnumerableInterpretable.java:113)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl$CalcitePreparingStmt.implement(CalcitePrepareImpl.java:1130)
> ...
> Suppressed: java.lang.NullPointerException: SqlTypeFamily for
> RecordType(INTEGER EXPR$0, VARCHAR(9)
[jira] [Comment Edited] (CALCITE-4434) Cannot implement 'CASE row WHEN row ...'
[
https://issues.apache.org/jira/browse/CALCITE-4434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17256194#comment-17256194
]
Rui Wang edited comment on CALCITE-4434 at 12/29/20, 10:45 PM:
---
I see. Sorry on that I wasn't check the commit message. As Zhen mentioned the
committed one wasn't the closed PR, but a new one.
[~zhenw]
if you create a new PR that address the Julian's comments and have a commit
message in right format ([JIRA] description (name) or you can check commits
history to see how people format their commits), I can review your PR again.
was (Author: amaliujia):
I see. Sorry on that I wasn't check the commit message. As Zhen mentioned the
committed one wasn't the closed PR, but a new one.
[~zhenw]
if you create a new PR that address the Julian's comments and have a commit
message in right format (you can check commits history to see how people format
their commits), I can review your PR again.
> Cannot implement 'CASE row WHEN row ...'
>
>
> Key: CALCITE-4434
> URL: https://issues.apache.org/jira/browse/CALCITE-4434
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Zhen Wang
>Priority: Major
> Labels: pull-request-available
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> Cannot implement 'CASE row WHEN row ...'.
> For example, the test
> {noformat}
> diff --git a/core/src/test/resources/sql/misc.iq
> b/core/src/test/resources/sql/misc.iq
> index 3c945e2cc..84ef67b6c 100644
> --- a/core/src/test/resources/sql/misc.iq
> +++ b/core/src/test/resources/sql/misc.iq
> @@ -1065,6 +1065,47 @@ Expression 'DEPTNO' is not being grouped
>
> !use scott
>
> +# [CALCITE-] Cannot implement 'CASE row WHEN row ...'
> +SELECT deptno, job,
> + CASE (deptno, job)
> + WHEN (20, 'CLERK') THEN 1
> + WHEN (30, 'SALESMAN') THEN 2
> + ELSE 3
> + END AS x
> +FROM "scott".emp
> +WHERE empno < 7600;
> +++--+---+
> +| DEPTNO | JOB | X |
> +++--+---+
> +| 20 | CLERK| 1 |
> +| 20 | MANAGER | 3 |
> +| 30 | SALESMAN | 2 |
> +| 30 | SALESMAN | 2 |
> +++--+---+
> +(4 rows)
> +!ok
> +
> +# Equivalent to previous
> +SELECT deptno, job,
> + CASE
> + WHEN deptno = 20 AND job = 'CLERK' THEN 1
> + WHEN deptno = 30 AND job = 'SALESMAN' THEN 2
> + ELSE 3
> + END AS x
> +FROM "scott".emp
> +WHERE empno < 7600;
> +++--+---+
> +| DEPTNO | JOB | X |
> +++--+---+
> +| 20 | CLERK| 1 |
> +| 20 | MANAGER | 3 |
> +| 30 | SALESMAN | 2 |
> +| 30 | SALESMAN | 2 |
> +++--+---+
> +(4 rows)
> +
> +!ok
> +
> {noformat}
> fails with the following stack trace:
> {noformat}
> Unable to implement EnumerableCalc(expr#0..7=[{inputs}], expr#8=[ROW($t7,
> $t2)], expr#9=[CAST($t8):RecordType(INTEGER EXPR$0, VARCHAR(9) EXPR$1) NOT
> NULL], expr#10=[20], expr#11=['CLERK'], expr#12=[ROW($t10, $t11)],
> expr#13=[CAST($t12):RecordType(INTEGER EXPR$0, VARCHAR(9) EXPR$1) NOT NULL],
> expr#14=[=($t9, $t13)], expr#15=[1], expr#16=[30], expr#17=['SALESMAN'],
> expr#18=[ROW($t16, $t17)], expr#19=[CAST($t18):RecordType(INTEGER EXPR$0,
> VARCHAR(9) EXPR$1) NOT NULL], expr#20=[=($t9, $t19)], expr#21=[2],
> expr#22=[3], expr#23=[CASE($t14, $t15, $t20, $t21, $t22)], expr#24=[7600],
> expr#25=[<($t0, $t24)], DEPTNO=[$t7], JOB=[$t2], X=[$t23],
> $condition=[$t25]): rowcount = 7.0, cumulative cost = {21.0 rows, 435.0 cpu,
> 0.0 io}, id = 49495
> EnumerableTableScan(table=[[scott, EMP]]): rowcount = 14.0, cumulative cost
> = {14.0 rows, 15.0 cpu, 0.0 io}, id = 49458
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:163)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:227)
> at net.hydromatic.quidem.Quidem.checkResult(Quidem.java:322)
> ...
> Caused by: java.lang.IllegalStateException: Unable to implement
> EnumerableCalc(expr#0..7=[{inputs}], expr#8=[ROW($t7, $t2)],
> expr#9=[CAST($t8):RecordType(INTEGER EXPR$0, VARCHAR(9) EXPR$1) NOT NULL],
> expr#10=[20], expr#11=['CLERK'], expr#12=[ROW($t10, $t11)],
> expr#13=[CAST($t12):RecordType(INTEGER EXPR$0, VARCHAR(9) EXPR$1) NOT NULL],
> expr#14=[=($t9, $t13)], expr#15=[1], expr#16=[30], expr#17=['SALESMAN'],
> expr#18=[ROW($t16, $t17)], expr#19=[CAST($t18):RecordType(INTEGER EXPR$0,
> VARCHAR(9) EXPR$1) NOT NULL], expr#20=[=($t9, $t19)], expr#21=[2],
> expr#22=[3], expr#23=[CASE($t14, $t15, $t20, $t21, $t22)], expr#24=[7600],
> expr#25=[<($t0, $t24)], DEPTNO=[$t7], JOB=[$t2], X=[$t23],
> $condition=[$t25]): rowcount =
[jira] [Commented] (CALCITE-4434) Cannot implement 'CASE row WHEN row ...'
[
https://issues.apache.org/jira/browse/CALCITE-4434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17256194#comment-17256194
]
Rui Wang commented on CALCITE-4434:
---
I see. Sorry on that I wasn't check the commit message. As Zhen mentioned the
committed one wasn't the closed PR, but a new one.
[~zhenw]
if you create a new PR that address the Julian's comments and have a commit
message in right format (you can check commits history to see how people format
their commits), I can review your PR again.
> Cannot implement 'CASE row WHEN row ...'
>
>
> Key: CALCITE-4434
> URL: https://issues.apache.org/jira/browse/CALCITE-4434
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Zhen Wang
>Priority: Major
> Labels: pull-request-available
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> Cannot implement 'CASE row WHEN row ...'.
> For example, the test
> {noformat}
> diff --git a/core/src/test/resources/sql/misc.iq
> b/core/src/test/resources/sql/misc.iq
> index 3c945e2cc..84ef67b6c 100644
> --- a/core/src/test/resources/sql/misc.iq
> +++ b/core/src/test/resources/sql/misc.iq
> @@ -1065,6 +1065,47 @@ Expression 'DEPTNO' is not being grouped
>
> !use scott
>
> +# [CALCITE-] Cannot implement 'CASE row WHEN row ...'
> +SELECT deptno, job,
> + CASE (deptno, job)
> + WHEN (20, 'CLERK') THEN 1
> + WHEN (30, 'SALESMAN') THEN 2
> + ELSE 3
> + END AS x
> +FROM "scott".emp
> +WHERE empno < 7600;
> +++--+---+
> +| DEPTNO | JOB | X |
> +++--+---+
> +| 20 | CLERK| 1 |
> +| 20 | MANAGER | 3 |
> +| 30 | SALESMAN | 2 |
> +| 30 | SALESMAN | 2 |
> +++--+---+
> +(4 rows)
> +!ok
> +
> +# Equivalent to previous
> +SELECT deptno, job,
> + CASE
> + WHEN deptno = 20 AND job = 'CLERK' THEN 1
> + WHEN deptno = 30 AND job = 'SALESMAN' THEN 2
> + ELSE 3
> + END AS x
> +FROM "scott".emp
> +WHERE empno < 7600;
> +++--+---+
> +| DEPTNO | JOB | X |
> +++--+---+
> +| 20 | CLERK| 1 |
> +| 20 | MANAGER | 3 |
> +| 30 | SALESMAN | 2 |
> +| 30 | SALESMAN | 2 |
> +++--+---+
> +(4 rows)
> +
> +!ok
> +
> {noformat}
> fails with the following stack trace:
> {noformat}
> Unable to implement EnumerableCalc(expr#0..7=[{inputs}], expr#8=[ROW($t7,
> $t2)], expr#9=[CAST($t8):RecordType(INTEGER EXPR$0, VARCHAR(9) EXPR$1) NOT
> NULL], expr#10=[20], expr#11=['CLERK'], expr#12=[ROW($t10, $t11)],
> expr#13=[CAST($t12):RecordType(INTEGER EXPR$0, VARCHAR(9) EXPR$1) NOT NULL],
> expr#14=[=($t9, $t13)], expr#15=[1], expr#16=[30], expr#17=['SALESMAN'],
> expr#18=[ROW($t16, $t17)], expr#19=[CAST($t18):RecordType(INTEGER EXPR$0,
> VARCHAR(9) EXPR$1) NOT NULL], expr#20=[=($t9, $t19)], expr#21=[2],
> expr#22=[3], expr#23=[CASE($t14, $t15, $t20, $t21, $t22)], expr#24=[7600],
> expr#25=[<($t0, $t24)], DEPTNO=[$t7], JOB=[$t2], X=[$t23],
> $condition=[$t25]): rowcount = 7.0, cumulative cost = {21.0 rows, 435.0 cpu,
> 0.0 io}, id = 49495
> EnumerableTableScan(table=[[scott, EMP]]): rowcount = 14.0, cumulative cost
> = {14.0 rows, 15.0 cpu, 0.0 io}, id = 49458
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:163)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:227)
> at net.hydromatic.quidem.Quidem.checkResult(Quidem.java:322)
> ...
> Caused by: java.lang.IllegalStateException: Unable to implement
> EnumerableCalc(expr#0..7=[{inputs}], expr#8=[ROW($t7, $t2)],
> expr#9=[CAST($t8):RecordType(INTEGER EXPR$0, VARCHAR(9) EXPR$1) NOT NULL],
> expr#10=[20], expr#11=['CLERK'], expr#12=[ROW($t10, $t11)],
> expr#13=[CAST($t12):RecordType(INTEGER EXPR$0, VARCHAR(9) EXPR$1) NOT NULL],
> expr#14=[=($t9, $t13)], expr#15=[1], expr#16=[30], expr#17=['SALESMAN'],
> expr#18=[ROW($t16, $t17)], expr#19=[CAST($t18):RecordType(INTEGER EXPR$0,
> VARCHAR(9) EXPR$1) NOT NULL], expr#20=[=($t9, $t19)], expr#21=[2],
> expr#22=[3], expr#23=[CASE($t14, $t15, $t20, $t21, $t22)], expr#24=[7600],
> expr#25=[<($t0, $t24)], DEPTNO=[$t7], JOB=[$t2], X=[$t23],
> $condition=[$t25]): rowcount = 7.0, cumulative cost = {21.0 rows, 435.0 cpu,
> 0.0 io}, id = 49495
> EnumerableTableScan(table=[[scott, EMP]]): rowcount = 14.0, cumulative cost
> = {14.0 rows, 15.0 cpu, 0.0 io}, id = 49458
> at
> org.apache.calcite.adapter.enumerable.EnumerableRelImplementor.implementRoot(EnumerableRelImplementor.java:114)
> at
> org.apache.calcite.adapter.enumerable.EnumerableInterpretable.toBindable(EnumerableInterpretable.java:113)
> at
[jira] [Commented] (CALCITE-4434) Cannot implement 'CASE row WHEN row ...'
[
https://issues.apache.org/jira/browse/CALCITE-4434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17255737#comment-17255737
]
Rui Wang commented on CALCITE-4434:
---
fixed via
https://github.com/apache/calcite/commit/9b272069091c649935c36a6bf26204b64b18ef44
Thanks [~zhenw] for your contribution!
> Cannot implement 'CASE row WHEN row ...'
>
>
> Key: CALCITE-4434
> URL: https://issues.apache.org/jira/browse/CALCITE-4434
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Priority: Major
> Labels: pull-request-available
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> Cannot implement 'CASE row WHEN row ...'.
> For example, the test
> {noformat}
> diff --git a/core/src/test/resources/sql/misc.iq
> b/core/src/test/resources/sql/misc.iq
> index 3c945e2cc..84ef67b6c 100644
> --- a/core/src/test/resources/sql/misc.iq
> +++ b/core/src/test/resources/sql/misc.iq
> @@ -1065,6 +1065,47 @@ Expression 'DEPTNO' is not being grouped
>
> !use scott
>
> +# [CALCITE-] Cannot implement 'CASE row WHEN row ...'
> +SELECT deptno, job,
> + CASE (deptno, job)
> + WHEN (20, 'CLERK') THEN 1
> + WHEN (30, 'SALESMAN') THEN 2
> + ELSE 3
> + END AS x
> +FROM "scott".emp
> +WHERE empno < 7600;
> +++--+---+
> +| DEPTNO | JOB | X |
> +++--+---+
> +| 20 | CLERK| 1 |
> +| 20 | MANAGER | 3 |
> +| 30 | SALESMAN | 2 |
> +| 30 | SALESMAN | 2 |
> +++--+---+
> +(4 rows)
> +!ok
> +
> +# Equivalent to previous
> +SELECT deptno, job,
> + CASE
> + WHEN deptno = 20 AND job = 'CLERK' THEN 1
> + WHEN deptno = 30 AND job = 'SALESMAN' THEN 2
> + ELSE 3
> + END AS x
> +FROM "scott".emp
> +WHERE empno < 7600;
> +++--+---+
> +| DEPTNO | JOB | X |
> +++--+---+
> +| 20 | CLERK| 1 |
> +| 20 | MANAGER | 3 |
> +| 30 | SALESMAN | 2 |
> +| 30 | SALESMAN | 2 |
> +++--+---+
> +(4 rows)
> +
> +!ok
> +
> {noformat}
> fails with the following stack trace:
> {noformat}
> Unable to implement EnumerableCalc(expr#0..7=[{inputs}], expr#8=[ROW($t7,
> $t2)], expr#9=[CAST($t8):RecordType(INTEGER EXPR$0, VARCHAR(9) EXPR$1) NOT
> NULL], expr#10=[20], expr#11=['CLERK'], expr#12=[ROW($t10, $t11)],
> expr#13=[CAST($t12):RecordType(INTEGER EXPR$0, VARCHAR(9) EXPR$1) NOT NULL],
> expr#14=[=($t9, $t13)], expr#15=[1], expr#16=[30], expr#17=['SALESMAN'],
> expr#18=[ROW($t16, $t17)], expr#19=[CAST($t18):RecordType(INTEGER EXPR$0,
> VARCHAR(9) EXPR$1) NOT NULL], expr#20=[=($t9, $t19)], expr#21=[2],
> expr#22=[3], expr#23=[CASE($t14, $t15, $t20, $t21, $t22)], expr#24=[7600],
> expr#25=[<($t0, $t24)], DEPTNO=[$t7], JOB=[$t2], X=[$t23],
> $condition=[$t25]): rowcount = 7.0, cumulative cost = {21.0 rows, 435.0 cpu,
> 0.0 io}, id = 49495
> EnumerableTableScan(table=[[scott, EMP]]): rowcount = 14.0, cumulative cost
> = {14.0 rows, 15.0 cpu, 0.0 io}, id = 49458
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:163)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:227)
> at net.hydromatic.quidem.Quidem.checkResult(Quidem.java:322)
> ...
> Caused by: java.lang.IllegalStateException: Unable to implement
> EnumerableCalc(expr#0..7=[{inputs}], expr#8=[ROW($t7, $t2)],
> expr#9=[CAST($t8):RecordType(INTEGER EXPR$0, VARCHAR(9) EXPR$1) NOT NULL],
> expr#10=[20], expr#11=['CLERK'], expr#12=[ROW($t10, $t11)],
> expr#13=[CAST($t12):RecordType(INTEGER EXPR$0, VARCHAR(9) EXPR$1) NOT NULL],
> expr#14=[=($t9, $t13)], expr#15=[1], expr#16=[30], expr#17=['SALESMAN'],
> expr#18=[ROW($t16, $t17)], expr#19=[CAST($t18):RecordType(INTEGER EXPR$0,
> VARCHAR(9) EXPR$1) NOT NULL], expr#20=[=($t9, $t19)], expr#21=[2],
> expr#22=[3], expr#23=[CASE($t14, $t15, $t20, $t21, $t22)], expr#24=[7600],
> expr#25=[<($t0, $t24)], DEPTNO=[$t7], JOB=[$t2], X=[$t23],
> $condition=[$t25]): rowcount = 7.0, cumulative cost = {21.0 rows, 435.0 cpu,
> 0.0 io}, id = 49495
> EnumerableTableScan(table=[[scott, EMP]]): rowcount = 14.0, cumulative cost
> = {14.0 rows, 15.0 cpu, 0.0 io}, id = 49458
> at
> org.apache.calcite.adapter.enumerable.EnumerableRelImplementor.implementRoot(EnumerableRelImplementor.java:114)
> at
> org.apache.calcite.adapter.enumerable.EnumerableInterpretable.toBindable(EnumerableInterpretable.java:113)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl$CalcitePreparingStmt.implement(CalcitePrepareImpl.java:1130)
> ...
> Suppressed: java.lang.NullPointerException: SqlTypeFamily for
> RecordType(INTEGER EXPR$0, VARCHAR(9) EXPR$1)
>
[jira] [Assigned] (CALCITE-4434) Cannot implement 'CASE row WHEN row ...'
[
https://issues.apache.org/jira/browse/CALCITE-4434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rui Wang reassigned CALCITE-4434:
-
Assignee: Zhen Wang
> Cannot implement 'CASE row WHEN row ...'
>
>
> Key: CALCITE-4434
> URL: https://issues.apache.org/jira/browse/CALCITE-4434
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Zhen Wang
>Priority: Major
> Labels: pull-request-available
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> Cannot implement 'CASE row WHEN row ...'.
> For example, the test
> {noformat}
> diff --git a/core/src/test/resources/sql/misc.iq
> b/core/src/test/resources/sql/misc.iq
> index 3c945e2cc..84ef67b6c 100644
> --- a/core/src/test/resources/sql/misc.iq
> +++ b/core/src/test/resources/sql/misc.iq
> @@ -1065,6 +1065,47 @@ Expression 'DEPTNO' is not being grouped
>
> !use scott
>
> +# [CALCITE-] Cannot implement 'CASE row WHEN row ...'
> +SELECT deptno, job,
> + CASE (deptno, job)
> + WHEN (20, 'CLERK') THEN 1
> + WHEN (30, 'SALESMAN') THEN 2
> + ELSE 3
> + END AS x
> +FROM "scott".emp
> +WHERE empno < 7600;
> +++--+---+
> +| DEPTNO | JOB | X |
> +++--+---+
> +| 20 | CLERK| 1 |
> +| 20 | MANAGER | 3 |
> +| 30 | SALESMAN | 2 |
> +| 30 | SALESMAN | 2 |
> +++--+---+
> +(4 rows)
> +!ok
> +
> +# Equivalent to previous
> +SELECT deptno, job,
> + CASE
> + WHEN deptno = 20 AND job = 'CLERK' THEN 1
> + WHEN deptno = 30 AND job = 'SALESMAN' THEN 2
> + ELSE 3
> + END AS x
> +FROM "scott".emp
> +WHERE empno < 7600;
> +++--+---+
> +| DEPTNO | JOB | X |
> +++--+---+
> +| 20 | CLERK| 1 |
> +| 20 | MANAGER | 3 |
> +| 30 | SALESMAN | 2 |
> +| 30 | SALESMAN | 2 |
> +++--+---+
> +(4 rows)
> +
> +!ok
> +
> {noformat}
> fails with the following stack trace:
> {noformat}
> Unable to implement EnumerableCalc(expr#0..7=[{inputs}], expr#8=[ROW($t7,
> $t2)], expr#9=[CAST($t8):RecordType(INTEGER EXPR$0, VARCHAR(9) EXPR$1) NOT
> NULL], expr#10=[20], expr#11=['CLERK'], expr#12=[ROW($t10, $t11)],
> expr#13=[CAST($t12):RecordType(INTEGER EXPR$0, VARCHAR(9) EXPR$1) NOT NULL],
> expr#14=[=($t9, $t13)], expr#15=[1], expr#16=[30], expr#17=['SALESMAN'],
> expr#18=[ROW($t16, $t17)], expr#19=[CAST($t18):RecordType(INTEGER EXPR$0,
> VARCHAR(9) EXPR$1) NOT NULL], expr#20=[=($t9, $t19)], expr#21=[2],
> expr#22=[3], expr#23=[CASE($t14, $t15, $t20, $t21, $t22)], expr#24=[7600],
> expr#25=[<($t0, $t24)], DEPTNO=[$t7], JOB=[$t2], X=[$t23],
> $condition=[$t25]): rowcount = 7.0, cumulative cost = {21.0 rows, 435.0 cpu,
> 0.0 io}, id = 49495
> EnumerableTableScan(table=[[scott, EMP]]): rowcount = 14.0, cumulative cost
> = {14.0 rows, 15.0 cpu, 0.0 io}, id = 49458
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:163)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:227)
> at net.hydromatic.quidem.Quidem.checkResult(Quidem.java:322)
> ...
> Caused by: java.lang.IllegalStateException: Unable to implement
> EnumerableCalc(expr#0..7=[{inputs}], expr#8=[ROW($t7, $t2)],
> expr#9=[CAST($t8):RecordType(INTEGER EXPR$0, VARCHAR(9) EXPR$1) NOT NULL],
> expr#10=[20], expr#11=['CLERK'], expr#12=[ROW($t10, $t11)],
> expr#13=[CAST($t12):RecordType(INTEGER EXPR$0, VARCHAR(9) EXPR$1) NOT NULL],
> expr#14=[=($t9, $t13)], expr#15=[1], expr#16=[30], expr#17=['SALESMAN'],
> expr#18=[ROW($t16, $t17)], expr#19=[CAST($t18):RecordType(INTEGER EXPR$0,
> VARCHAR(9) EXPR$1) NOT NULL], expr#20=[=($t9, $t19)], expr#21=[2],
> expr#22=[3], expr#23=[CASE($t14, $t15, $t20, $t21, $t22)], expr#24=[7600],
> expr#25=[<($t0, $t24)], DEPTNO=[$t7], JOB=[$t2], X=[$t23],
> $condition=[$t25]): rowcount = 7.0, cumulative cost = {21.0 rows, 435.0 cpu,
> 0.0 io}, id = 49495
> EnumerableTableScan(table=[[scott, EMP]]): rowcount = 14.0, cumulative cost
> = {14.0 rows, 15.0 cpu, 0.0 io}, id = 49458
> at
> org.apache.calcite.adapter.enumerable.EnumerableRelImplementor.implementRoot(EnumerableRelImplementor.java:114)
> at
> org.apache.calcite.adapter.enumerable.EnumerableInterpretable.toBindable(EnumerableInterpretable.java:113)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl$CalcitePreparingStmt.implement(CalcitePrepareImpl.java:1130)
> ...
> Suppressed: java.lang.NullPointerException: SqlTypeFamily for
> RecordType(INTEGER EXPR$0, VARCHAR(9) EXPR$1)
> at java.base/java.util.Objects.requireNonNull(Objects.java:348)
> at
>
[jira] [Commented] (CALCITE-4375) Merge join condition that has "OR" as much as possible
[ https://issues.apache.org/jira/browse/CALCITE-4375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17225593#comment-17225593 ] Rui Wang commented on CALCITE-4375: --- [~Aron.tao] what would be the benefit of this change? > Merge join condition that has "OR" as much as possible > -- > > Key: CALCITE-4375 > URL: https://issues.apache.org/jira/browse/CALCITE-4375 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Major > > SQL: > SELECT * FROM emps,depts > WHERE > (emps.name = depts.name AND empno=1) > OR > (emps.name = depts.name AND empno=2) > > And the join after optimizer is: > EnumerableNestedLoopJoin(condition=[OR(AND(=($1, $11), =($0, 1)), AND(=($1, > $11), =($0, 2)))], joinType=[inner]) > > In fact ($1, $11) can be extracted, and the join can be: > HashJoin(condition=[AND(=($1, $11), OR(=($0, 1), =($0, 2)))], > joinType=[inner]) > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4341) Support double/float mod
[ https://issues.apache.org/jira/browse/CALCITE-4341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17215566#comment-17215566 ] Rui Wang commented on CALCITE-4341: --- Can you add descriptions to this JIRA? > Support double/float mod > > > Key: CALCITE-4341 > URL: https://issues.apache.org/jira/browse/CALCITE-4341 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4337) Supports PARTITION BY clause for table function table argument
[
https://issues.apache.org/jira/browse/CALCITE-4337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214379#comment-17214379
]
Rui Wang commented on CALCITE-4337:
---
GROUP BY can pass though group by keys only without aggregation function.
Though it might not be suitable to your use case.
Yes SESSION TVF does not need to couple with GROUP BY. If that does not work as
a workaround, PARTITION BY will be a good choice.
> Supports PARTITION BY clause for table function table argument
> --
>
> Key: CALCITE-4337
> URL: https://issues.apache.org/jira/browse/CALCITE-4337
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Affects Versions: 1.26.0
>Reporter: Danny Chen
>Assignee: Danny Chen
>Priority: Major
> Fix For: 1.27.0
>
>
> An example from the SQL standard 2016 Polymorphic Table Functions:
> {code:sql}
> SELECT W.wstart, W.wend, OI.customer, SUM(OI.price)
> FROM TABLE(SESSION(
> data => TABLE(order_item) AS OI PARTITION BY customer,
> timecol => DESCRIPTOR(order_time),
> timeout => INTERVAL '10' MINUTE)) W
> GROUP BY 1, 2, 3
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4337) Supports PARTITION BY clause for table function table argument
[
https://issues.apache.org/jira/browse/CALCITE-4337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214101#comment-17214101
]
Rui Wang commented on CALCITE-4337:
---
O I guess you want partition a table or stream by customer then applying
inactive session, and you need an explicit partitioning to allow optimizer do
something?
In this case, a workaround will be use GROUP BY but use a new rule to merge
GROUP BY and TableFunctionScan. But I am not sure which one is more complicated
to implement.
> Supports PARTITION BY clause for table function table argument
> --
>
> Key: CALCITE-4337
> URL: https://issues.apache.org/jira/browse/CALCITE-4337
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Affects Versions: 1.26.0
>Reporter: Danny Chen
>Assignee: Danny Chen
>Priority: Major
> Fix For: 1.27.0
>
>
> An example from the SQL standard 2016 Polymorphic Table Functions:
> {code:sql}
> SELECT W.wstart, W.wend, OI.customer, SUM(OI.price)
> FROM TABLE(SESSION(
> data => TABLE(order_item) AS OI PARTITION BY customer,
> timecol => DESCRIPTOR(order_time),
> timeout => INTERVAL '10' MINUTE)) W
> GROUP BY 1, 2, 3
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4337) Supports PARTITION BY clause for table function table argument
[
https://issues.apache.org/jira/browse/CALCITE-4337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214093#comment-17214093
]
Rui Wang commented on CALCITE-4337:
---
Thanks Danny to file this Jira. also cc [~jark] to move discussions here.
Another question of mine is, will a GROUP BY help you partition the table
function and also enable adding exchange operator by optimizer?
I agree PARTITION BY is defined by SQL standard and we can support it. But
before that, just trying to understand your use case and see if existing syntax
can help.
> Supports PARTITION BY clause for table function table argument
> --
>
> Key: CALCITE-4337
> URL: https://issues.apache.org/jira/browse/CALCITE-4337
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Affects Versions: 1.26.0
>Reporter: Danny Chen
>Assignee: Danny Chen
>Priority: Major
> Fix For: 1.27.0
>
>
> An example from the SQL standard 2016 Polymorphic Table Functions:
> {code:sql}
> SELECT W.wstart, W.wend, OI.customer, SUM(OI.price)
> FROM TABLE(SESSION(
> data => TABLE(order_item) AS OI PARTITION BY customer,
> timecol => DESCRIPTOR(order_time),
> timeout => INTERVAL '10' MINUTE)) W
> GROUP BY 1, 2, 3
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3780) SESSION Table-valued Function
[
https://issues.apache.org/jira/browse/CALCITE-3780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17213572#comment-17213572
]
Rui Wang commented on CALCITE-3780:
---
[~jark] I don't have a plan to support PARTITION BY syntax because I think that
syntax is supported by the DESCRIPTOR(key) parameter for SESSION window. Do you
have a case that PARTITION BY syntax can support but DESCRIPTOR(key) cannot?
> SESSION Table-valued Function
> -
>
> Key: CALCITE-3780
> URL: https://issues.apache.org/jira/browse/CALCITE-3780
> Project: Calcite
> Issue Type: Sub-task
>Reporter: Rui Wang
>Assignee: Rui Wang
>Priority: Major
> Fix For: 1.23.0
>
>
> We can create SESSION table-valued function to replace GROUP BY SESSION for
> inactive gap session functionality:
> {code:sql}
> SELECT *
> FROM TABLE SESSION (
> data => TABLE Bid ,
> timecol => DESCRIPTOR ( bidtime ) ,
> keycol => DESCRIPTOR(key),
> inactive_gap => INTERVAL '10' MINUTES )
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
