Rui Wang created CALCITE-3343:
-
Summary: Improve LogicalTableFunctionScan to match table function
windowing
Key: CALCITE-3343
URL: https://issues.apache.org/jira/browse/CALCITE-3343
Project: Calcite
We are using calcite to query data in Kudu. We have implemented our own
sort rule that merges rows returned from kudu when a queries orders by
columns in the same order as the primary key of the kudu table.
For a query that does a left join, in order to get the planner to use my
sort rule I had to
I noticed the problem thanks to Andrei but I underestimated its importance.
Sorry about that!
On Thu, Sep 12, 2019 at 4:35 PM Julian Hyde wrote:
> Yes, I screwed up. Everyone who voted screwed up. I should have voted ‘-1’
> because the hash of the artifacts I got from svn did not match the
Jess Balint created CALCITE-3342:
Summary: sqltorelconverter adds extra fields with order by
Key: CALCITE-3342
URL: https://issues.apache.org/jira/browse/CALCITE-3342
Project: Calcite
Issue
Julian Feinauer created CALCITE-3341:
Summary: Implement FINAL modifier functionality
Key: CALCITE-3341
URL: https://issues.apache.org/jira/browse/CALCITE-3341
Project: Calcite
Issue
Yes, I screwed up. Everyone who voted screwed up. I should have voted ‘-1’
because the hash of the artifacts I got from svn did not match the hash in the
email. Let’s all do better next time.
Still, no harm done. We know now that we were voting on the correct artifacts.
We have a valid
+1 to everything Vladmir said. Thanks for the release Stamatis! I do
agree that the checksum issue shouldn't be ignored although an update
from the RM to the vote thread should be sufficient. Really, we rely
on the email of the RM not being compromised anyway if we assume we
can have a MITM
Thanks everybody for helpful comments.
At this point I'm confident the change is good, so I'm inclined to just
commit it and cleanup glitches later if any.
I'm inclined to remove pom.xml files from Git control as well.
PS. There was Gradle-produced release candidate. You can find it under the
Hi Han,
I guess what you are looking for is RelFieldTrimmer [1] and it is not
implemented as a transformation rule but as a separate optimization phase
in this case.
Best,
Stamatis
[1]
Hi Shubham,
View based rewriting is performed during planning (check the call hierarchy
of [1] for more details).
If you obtain a plan (RelNode) after the planner then most likely rel2sql
API should give you the right SQL string.
On the other hand if you are just using sql2rel API then rewritings
Stamatis, thanks for your work on this.
Stamatis>The checksum hash that was communicated in the vote email was wrong
Stamatis>given
Stamatis>that the correct one was send along with the artifacts and people
used this
Stamatis>for the checks I assume there is no problem.
I'm inclined that we
Hi Feng,
You’re right, i get the same result with your suggestion, and either of the
following expressions is ok.
1. properties.put(CalciteConnectionProperty.LEX.camelName(), "MYSQL");
2. properties.put("lex", "MYSQL");
You’re familiar with Calcite :), and thanks for your help and
Hi, Juan Pan:
You may find the logic in *UnregisterDriver#connect(String url, Properties
info)*
It just parses the key-value pairs in url's prefix and adds into the copy
of "info".
Therefore, I think the below config
*properties.put(CalciteConnecti**onProperty.LEX, Lex.MYSQL); *
should be aligned
Hi all,
I’m learning query optimization recently. As known, Calcite uses a volcano
optimizer which is different from other optimizers such as SparkSQL’s Catalyst.
But I’m curious how does volcano optimizer implement rules like `ColumnPruning`
in Catalyst? Or which transformation rule does
Hi,
Personally, I'd be happy to contribute it -- it's currently MIT licensed
(as a matter of convention of my employer), but I'll double-check with my
employer about whether there are any qualms about just contributing it to
the project directly.
For now, it's certainly fine with me if you link
Hi Julian,
On Tue, Sep 10, 2019 at 5:19 PM Julian Feinauer <
j.feina...@pragmaticminds.de> wrote:
>
> when going through the Code I just had another Idea.
> Currently a TableFunction is executed as EnumerableTableFunctionScan which
> gets generated from a LogicalTableFunctionScan by the Rule
>
Hi Feng,
Thanks for your promote reply. :)
Lex is just what i want. But when i tried to use it, i encountered another
problem.
The first usage is ok, but the second one doesn’t work. ThoughLex are used in
different methods, the result will be same, i think. Do i misunderstand?
17 matches
Mail list logo
