Review Request for CALCITE-2528. Support Aggregates in ElasticSearch Adapter

Hello, Can somebody please review the following PR: 822 (CALCITE-2528 ) ? It enhances ElasticSearch adapter with native ES aggregations

Re: PR 3495 (Make single-row rels unique) Review Request

These links are easier: * https://github.com/apache/calcite/pull/3495 * https://issues.apache.org/jira/browse/CALCITE-6044 > On Nov 16, 2023, at 7:51 AM, Paul Jackson > wrote: > > This PR updates org.apache.calcite.rel.metadata areColumnsUnique, > getUniqueKeys, and getPredicates methods to a

Re: PR 3495 (Make single-row rels unique) Review Request

Thanks. Is there a trick to sending e-mails to this list so that formatting is retained? Experimenting with my client's plain-text mode: https://github.com/apache/calcite/pull/3495 https://issues.apache.org/jira/projects/CALCITE/issues/CALCITE-6044 Copy/pasting your links: * https://github.com/

Re: PR 3495 (Make single-row rels unique) Review Request

It depends on your client. Different clients have a different notion of paragraph. Safest thing is to compose in plain text mode. Failing that, compose in rich text mode with the knowledge that it will be converted to plain text mode. Use ' * ' for bullet points, '>' for quoted text, and ridiculou

Re: PR 3495 (Make single-row rels unique) Review Request

Is there anything else to do for this PR? * https://github.com/apache/calcite/pull/3495 * https://issues.apache.org/jira/browse/CALCITE-6044 Thanks, -Paul > On Nov 16, 2023, at 7:51 AM, Paul Jackson > wrote: > > This PR updates org.apache.calcite.rel.metadata areColumnsUnique, > getUniqueK

Re: PR 3495 (Make single-row rels unique) Review Request

CI failed, so perhaps you can look into that. Mihai From: Paul Jackson Sent: Monday, January 8, 2024 7:06 AM To: dev@calcite.apache.org Subject: Re: PR 3495 (Make single-row rels unique) Review Request Is there anything else to do for this PR? * https

Re: PR 3495 (Make single-row rels unique) Review Request

ct: Re: PR 3495 (Make single-row rels unique) Review Request > > Is there anything else to do for this PR? > > * https://github.com/apache/calcite/pull/3495 > * https://issues.apache.org/jira/browse/CALCITE-6044 > > Thanks, > -Paul > > > > On Nov 16,

Re: PR 3495 (Make single-row rels unique) Review Request

Mihai Budiu wrote: > > CI failed, so perhaps you can look into that. > > Mihai > > From: Paul Jackson > Sent: Monday, January 8, 2024 7:06 AM > To: dev@calcite.apache.org > Subject: Re: PR 3495 (Make single-row rels unique) Review Reque

Re: PR 3495 (Make single-row rels unique) Review Request

k into that. >> >> Mihai >> >> From: Paul Jackson >> Sent: Monday, January 8, 2024 7:06 AM >> To: dev@calcite.apache.org >> Subject: Re: PR 3495 (Make single-row rels unique) Review Request >> >> Is t

Review Request (CALCITE-2689). ElasticSearch Adapter. Grouping on date / number fields.

Greetings , We have discovered an issue with ES aggregations when grouping on non-textual fields (date, long). Currently the following sql fails because for missing value

Review request: CALCITE-4652 (fix AggregateExpandDistinctAggregatesRule when SUM type is expanded)

Hi, Please review the patch for the issue CALCITE-4652 [1], see PR#2439 [2]. I tried to draw attention to the issue in the topic: "[HELP] Return type of the SUM aggregate function and AggregateExpandDistinctAggregatesRule​", but did not receive any answer, so I do not give a link to the discus

Review request: Babel parser doesn't parse IF(condition, then, else) statement

Babel parser doesn't parse IF(condition, then, else) statement because babel puts `IF` into the keyword set. I put `IF` into the reserved function name set to fix the issue: https://issues.apache.org/jira/browse/CALCITE-4802 Welcome to comment. Here is PR: https://github.com/apache/calcite/pull/2

Review request: Babel parser doesn't parse IF(condition, then, else) statements

`IF(condition, then, else)` is a common expression, babel parser failed because CALCITE-3946 put `IF` into the keywords list. I added it to reservedFunctionNames, here is PR: https://github.com/apache/calcite/pull/2835

[REVIEW REQUEST] [CALCITE-5279] Fix asymmetric keyword not supported by Firebolt

Hi, I would like to request a PR review for CALCITE-5279, which fixes the Firebolt dialect (as it does not support the 'asymmetric' keyword). PR: https://github.com/apache/calcite/pull/2904 Ticket: https://issues.apache.org/jira/browse/CALCITE-5279 Thank you ! Aymeric

Review Request. CALCITE-2588. Run Geode Adapter tests with an Embedded Instance

Hello, I have prepared a PR to execute Geode tests as part of regular CI build (or IDE test). Similarly to what has been done for Mongo / Elastic / Cassandra. Thank you, Vladimir, for reviewing it. Others are also welcome to take a look. If nobody objects, I will commit these changes in a coupl

Re: Review Request (CALCITE-2689). ElasticSearch Adapter. Grouping on date / number fields.

I haven't had a chance to review but saw that Elastic has the same issue with aggregations. https://github.com/elastic/elasticsearch/issues/35745 Kevin Risden On Wed, Nov 28, 2018, 20:46 Andrei Sereda Greetings , > We have discovered an issue with ES aggregations when grouping on > non-textual

Re: Review Request (CALCITE-2689). ElasticSearch Adapter. Grouping on date / number fields.

Interesting. One of the benefits that a SQL layer such as Calcite can bring is that it hides the details necessary to make operations like this work. Julian > On Dec 1, 2018, at 5:22 AM, Kevin Risden wrote: > > I haven't had a chance to review but saw that Elastic has the same issue > with a

Re: Review Request (CALCITE-2689). ElasticSearch Adapter. Grouping on date / number fields.

Hi Andrei, I haven't gone entirely over the new PR, but I think there are cases where the result of the queries are going to be wrong (when values collide with sentinels). Another approach would be to introduce a rule in order to push the aggregation in ElasticSearch *only* if the field in questio

Re: Review Request (CALCITE-2689). ElasticSearch Adapter. Grouping on date / number fields.

Thanks, Stamatis. I agree that sentinels are not the best approach but without pushing aggregations to ES they're not very usable to elastic users. So there are two bad choices: 1) (Low?) Probability of collisions triggering invalid results (surprises) but efficient query. 2) Inefficient query (

Re: Review Request (CALCITE-2689). ElasticSearch Adapter. Grouping on date / number fields.

I have no strong opinion since I am not using the adapter. However, I have a small question regarding option 2. Is the query still going to be inefficient if the user adds the IS NOT NULL predicate? If yes, then I probably option 1 would be the best option for the moment. Otherwise, I don't find

Re: Review Request (CALCITE-2689). ElasticSearch Adapter. Grouping on date / number fields.

> Is the query still going to be inefficient if the user adds the IS NOT NULL predicate? It will be efficient. For explicit null check aggregates can be pushed to ES since sentinel will never be used. > Otherwise, I don't find it very problematic to expect the users to right their queries correclt

[Review request] (CALCITE-2554) Enrich enumerable join operators with order preserving information

Hello, Can somebody have a look in the PR. Enriching join operators with RelCollation information can have a big impact in performance of some queries since it allows dropping redundant sort operators which are in general costly to evaluate. Thanks in advance, Stamatis JIRA: https://issues.apac

Re: Review request: CALCITE-4652 (fix AggregateExpandDistinctAggregatesRule when SUM type is expanded)

Hi. Ledkov. I'll do some code reviews in the next two days. Taras Ledkov 于2021年7月12日周一 下午7:58写道： > Hi, > > Please review the patch for the issue CALCITE-4652 [1], see PR#2439 [2]. > > I tried to draw attention to the issue in the topic: > "[HELP] Return type of the SUM aggregate function and > A

Re: Review request: CALCITE-4652 (fix AggregateExpandDistinctAggregatesRule when SUM type is expanded)

Hi Calcite Devs. I just remind about review/merge the patch for the issue CALCITE-4652 [1], see PR#2439 [2]. I've fixed the patch according with Julian comments. Also PR contains two 'LGTM' comments. Is the patch ready for merge? [1]. https://issues.apache.org/jira/browse/CALCITE-4652 [2]. ht

[REVIEW-REQUEST] [CALCITE-4790] Make Gradle pass the 'user.timezone' to test JVM

Hello everyone, can someone with some spare cycles check this 1 line PR: https://github.com/apache/calcite/pull/2534 We all agree that tests must pass in all timezones, but since we have CI jobs running in different timezones, it would be nice to be able to easily test under the same conditions ev

Re: Review request: Babel parser doesn't parse IF(condition, then, else) statements

Jiajun, thanks for your contribution, I'll review this. Jiajun Xie 于2022年8月5日周五 10:55写道： > `IF(condition, then, else)` is a common expression, babel parser failed > because CALCITE-3946 put `IF` into the keywords list. > > I added it to reservedFunctionNames, here is PR: > https://github.com

Re: [Review request] (CALCITE-2554) Enrich enumerable join operators with order preserving information

Stamatis, I left a comment on the PR. Overall it looks great to me although I wonder if we want to resolve CALCITE-2582 first to avoid disabling the subquery tests. Thanks! -- Michael Mior mm...@apache.org Le jeu. 3 janv. 2019 à 11:09, Stamatis Zampetakis a écrit : > Hello, > > Can somebody h

Review request for CALCITE-1912: Support "FOR SYSTEM_TIME AS OF" in regular queries

Hey all, There is a PR that has sort of been forgotten and the contributor would like to have it reviewed. Can someone please review it? Link to PR: https://github.com/apache/calcite/pull/759 JIRA issue: https://issues.apache.org/jira/browse/CALCITE-1912 Francis

Re: Review request for CALCITE-1912: Support "FOR SYSTEM_TIME AS OF" in regular queries

Hi Francis, Thank you for bring it here. The “FOR SYSTEM_TIME AS OF” operation is introduced in SQL:2011 temporal feature. It is a standard way to do a temporal table join using this syntax which we want to support in Apache Flink. We will be very grateful if anyone can review it. Thanks, Jar

Review request: CALCITE-4818 (AggregateExpandDistinctAggregatesRule must infer correct data type for top aggregate calls)

Hi, Please review the patch for the issue CALCITE-4818 [1], see PR#2560 [2]. Looks like the rule 'AggregateExpandDistinctAggregatesRule' contains another bug with inferring result type of the top aggregate calls. e.g. If the type system expand sum type like postgress: SUM(TINYINT | SMALLINT

Re: Review request: CALCITE-4818 (AggregateExpandDistinctAggregatesRule must infer correct data type for top aggregate calls)

Hi, Gently reminder about review. On 04.10.2021 20:30, Taras Ledkov wrote: Hi, Please review the patch for the issue CALCITE-4818 [1], see PR#2560 [2]. Looks like the rule 'AggregateExpandDistinctAggregatesRule' contains another bug with inferring result type of the top aggregate calls. e.

Re: Review request: CALCITE-4818 (AggregateExpandDistinctAggregatesRule must infer correct data type for top aggregate calls)

Hi Calcite team, Gently reminder about review / merge the patch for  CALCITE-4818 [1] [1]. https://issues.apache.org/jira/browse/CALCITE-4818 On 15.10.2021 15:16, Taras Ledkov wrote: Hi, Gently reminder about review. On 04.10.2021 20:30, Taras Ledkov wrote: Hi, Please review the patch for

<    1   2