Subramanya wrote:
Thanks a lot for your help.
Would you happen to have any insights into where exactly the time is spent
during the warm up?
On Tue, Aug 22, 2023 at 11:58 PM Roman Kondakov
wrote:
Hi Abhijit,
Usually the very first query is optimized a bit long in Calcite. But
after some warm
Hi Abhijit,
Usually the very first query is optimized a bit long in Calcite. But
after some warm-up the next queries will be planned faster and faster.
If you use Calcite as a part of a server application, then the problem
with a long query planning will be eliminated after a few query runs.
Hi Minseok,
I'm not sure I fully understand your requirements. But I think that
Correlate/EnumerableCorrelate may be useful in your case. It is similar
to nested loop join, but it adds an additional filter for the right side
with the correlation variable (cor0):
the logical plans rather than our custom ones. Is it possible to
utilize the physical nodes with MultiJoin or does it have to be utilized
with logical nodes only?
--Jonathan Sternberg
On Tue, Jul 4, 2023 at 1:43 AM Roman Kondakov
wrote:
Hi Jonathan,
1. As Julian mentioned, it's better to use
Hi Jonathan,
1. As Julian mentioned, it's better to use heuristic join order for
large amount of joins
2. LoptOptimizeJoinRule and MultiJoinOptimizeBushyRule AFAIK always
produce tree of joins, not a MultiJoin.
3. Yes, your understanding is correct. You can check the default join
order
Hi Vladislav,
Can you share more details regarding your use case?
If you want to share the same object between join inputs, you can use
RelShuttleImpl [1] to traverse the RelNode tree and every time you are
visiting a Join relation you need to put the object to the stack and
remove it from
Roman Kondakov created CALCITE-5670:
---
Summary: Assertion error in SemiJoinJoinTransposeRule
Key: CALCITE-5670
URL: https://issues.apache.org/jira/browse/CALCITE-5670
Project: Calcite
Issue
Hello Pranav,
you also can split your optimization process into several steps. For
example you can add a heuristic phase (using HEP planner) before Volcano
planning with filters pushdown. It is almost always a beneficial
operation so you can avoid polluting search space with plans that are
Roman Kondakov created CALCITE-5170:
---
Summary: Assertion error on range distribution creation
Key: CALCITE-5170
URL: https://issues.apache.org/jira/browse/CALCITE-5170
Project: Calcite
Roman Kondakov created CALCITE-5166:
---
Summary: Method accept(RelShuttle) is not overridden in
LogicalCalc and LogicalTableModify
Key: CALCITE-5166
URL: https://issues.apache.org/jira/browse/CALCITE-5166
[1] https://lists.apache.org/thread/cykl74dcphgow4790fwoc8frsjglz7n1
[2] https://issues.apache.org/jira/browse/CALCITE-4542
--
Roman Kondakov
On 11.02.2022 19:15, Alessandro Solimando wrote:
Hello everyone,
@Vladimir, +1 on the change introducing "enforceDerive()".
@Roman, could you walk us thr
Hi Vladimir,
+1 for making the rule driver more public. We've faced similar problems
in the downstream project. The solution was to copy and paste the
TopDownRuleDrive code with small fixes since it was not possible to
override the default behavior.
--
Roman Kondakov
On 11.02.2022 02:50
Hi, Yogendra
there is an utility method RelOptUtil#findAllTables that looks for all
tables in the rel tree. It doesn't collect column names, but you can
adopt it for this purpose.
It seems to me that solution with visitor should also work fine.
--
Roman Kondakov
On 07.02.2022 12:45, Zhe
Hi Rana,
there also should be a debugging information included into the
exception: long list of sets, subsets and relational nodes. Could you
please send it?
Roman Kondakov
On 21.07.2021 09:27, Rana Alotaibi wrote:
Hi Calcite Dev, Thanks for Calcite!
I'm currently using Calcite Core
Congratulations, Vladimir!
Roman Kondakov
On 24.06.2021 12:23, 段雄 wrote:
Congratulations!
XING JIN 于2021年6月24日周四 上午10:21写道：
Congratulations ~
Best,
Jin
guangyuan wang 于2021年6月24日周四 上午9:50写道：
Congratulations!
Francis Chuang 于2021年6月24日周四 上午6:39写道：
Congrats, Vladimir!
Francis
Hi Atri,
you can refer to this list [1]. I also aware that Apache Ignite and
Hazelcast made some efforts to employ Calcite as a distributed query
planner.
[1] https://calcite.apache.org/docs/powered_by.html
--
Roman Kondakov
On 14.05.2021 14:31, Atri Sharma wrote:
Is there an example I
Roman Kondakov created CALCITE-4590:
---
Summary: Incorrect query result with fixed-length string
Key: CALCITE-4590
URL: https://issues.apache.org/jira/browse/CALCITE-4590
Project: Calcite
/r38ea71968c069f465921e7197488329c15413b46831c90ad4d48f87e%40%3Cdev.calcite.apache.org%3E
[4]
https://lists.apache.org/thread.html/d1ce6e5201ba1a91a28da968f3294d7c09b1649fbfd3fb131231fede%40%3Cdev.calcite.apache.org%3E
--
Roman Kondakov
On 04.03.2021 10:42, Priyendra Deshwal wrote:
Hello friends,
What is the best resource
-to-apache-calcite
[3] https://github.com/apache/ignite
[4] https://github.com/apache/drill
[5] https://github.com/hazelcast/hazelcast
[6] https://calcite.apache.org/docs/powered_by.html
--
Roman Kondakov
On 11.08.2020 20:09, Abhishek Dasgupta wrote:
Hi Team,
I am working as a Software Developer in data
/blob/f64cdcbb9f6535650f0227da19640e736496a9c3/core/src/test/java/org/apache/calcite/plan/RelWriterTest.java#L88
--
Roman Kondakov
On 07.07.2020 22:13, Enrico Olivelli wrote:
Rui
Il Mar 7 Lug 2020, 20:30 Rui Wang ha scritto:
Hi Community,
In Apache Beam we are facing a use case where we need
Hi Aron,
there was a small discussion about this several months ago [1].
[1] https://github.com/apache/calcite/pull/1840#discussion_r387967624
--
Roman Kondakov
On 07.07.2020 09:52, JiaTao Tao wrote:
Seems only use OPTIMIZE phase, can we remove this mechanism?
Regards!
Aron Tao
search inflation vs more plan alternatives.
Thank you!
--
Kind Regards
Roman Kondakov
On 03.06.2020 05:42, Haisheng Yuan wrote:
>> using this approach, bitmap indexes may be represented as set operations
>> (union, intersect) over idx_a and idx_b followed by joining with scan_A
>
is an index on foo.a, but no index on bar.f.
Thank you!
--
Kind Regards
Roman Kondakov
On 02.06.2020 19:55, Julian Hyde wrote:
> Vladimir,
>
> I feel the same way. MVs are more powerful and general, and with some effort
> they could be just as efficient as other approac
in scenarios when the
number of indexes is very high. But may be there are some other advantages?
Thank you!
[1]
https://github.com/apache/drill/blob/master/exec/java-exec/src/main/java/org/apache/drill/exec/planner/index/rules/DbScanToIndexScanPrule.java
--
Kind Regards
Roman Kondakov
On 01.06.2020
can(B.b)? Or am I missing the crucial point of a rule-base
approach?
Thank you in advance!
--
Kind Regards
Roman Kondakov
On 31.05.2020 21:39, Vladimir Ozerov wrote:
> As already mentioned, the fundamental problem with "indexes as materialized
> views" approach is that you
scades-style optimizer become a part of Calcite, the search space
pollution will not be a serious issue anymore.
Thanks!
[1]
https://blogs.oracle.com/optimizer/optimizer-transformations:-or-expansion
--
Kind Regards
Roman Kondakov
On 31.05.2020 07:31, Haisheng Yuan wrote:
> Thanks J
rly you can look at
`IgnitePlanner.materializations()' method which registers indexes as
materialized views and `IgniteTableScan` which performs filter
conditions assessment and index scan cost estimation.
[1] https://github.com/apache/ignite/pull/7813
--
Kind Regards
Roman Kondakov
On 29.05.2
--
Kind Regards
Roman Kondakov
On 11.05.2020 11:12, Jinpeng Wu wrote:
> Hi, Roman.
>
> Thanks to Julian's tips, I added a CoreCascadeQuidemTest to the code. It
> runs iq files that CoreQuidemTest would runs and uses CascadePlanner
> instead of VolcanoPlanner to generate physical plans
Hi Haisheng,
I would like to review CALCITE-3896. Do you have a PR?
--
Kind Regards
Roman Kondakov
On 05.05.2020 06:37, Haisheng Yuan wrote:
> IIRC, I am the release manager for 1.23.0.
>
> I think CALCITE-3896 (top-down trait request) is in good shape, it will be
> nice
Roman Kondakov created CALCITE-3969:
---
Summary: Method RelTrait.apply(Mappings.Mapping) throws exception
when mapping doesn't cover collation or distribution keys
Key: CALCITE-3969
URL: https://issues.apache.org
he prototype: rules are matched on demand in the
top-down way (see org.apache.calcite.plan.cascades.ApplyRule.Bindery
class). And I believe that all other things (like creating physical
nodes) we can fix in the similar way: just changing the planner code
while maintaining backward compatibility
in org.apache.calcite.plan.volcano package, but they use synthetic
conventions and nodes. May be I missed something.
Thank you for sharing your work!
--
Kind Regards
Roman Kondakov
On 28.04.2020 15:19, Jinpeng Wu wrote:
> Hi, Roman. It's great to see your proposal. Actually my team has also been
> w
views
- hints
- multiple convetions
- listener hooks
- problems from p.3.
5. new PR, review and merge.
6. Replacie Volcano planner wiith Cascades after several releases.
What do you think about this roadmap?
--
Kind Regards
Roman Kondakov
On 27.04.2020 01:55, Stamatis Zampetakis wrote:
> Hi a
about this planner.
[1] PR: https://github.com/apache/calcite/pull/1948
[2] Paper:
https://15721.courses.cs.cmu.edu/spring2019/papers/22-optimizer1/xu-columbia-thesis1998.pdf
[3] Design doc:
https://docs.google.com/document/d/1qaV3eSKTw4gfLuBR3XB_LVIc51hxIng9k1J4VD6qnRg/edit?usp=sharing
--
Kind Regards
a#L476
--
Kind Regards
Roman Kondakov
On 11.04.2020 14:22, Tim Fox wrote:
> Hi All,
>
> I have recently started using Calcite as the query parser/planner for a
> side project. I have created a set of RelNodes corresponding to my physical
> nodes, and a set of rules. I have crea
Roman Kondakov created CALCITE-3885:
---
Summary: Reestablish trace logging for rules queue and Volcano
planner
Key: CALCITE-3885
URL: https://issues.apache.org/jira/browse/CALCITE-3885
Project
Hi everybody!
My name is Roman Kondakov. I use Calcite for building SQL layer on the
top of Apache Ignite.
I would like to join the Calcite community. I will start with minor
tasks (I have a couple on my mind) to understand your processes better.
I would also appreciate any help.
My Jira id
ied to planner?
Thanks.
[1]
https://www.slideshare.net/JordanHalterman/introduction-to-apache-calcite
--
Kind Regards
Roman Kondakov
On 03.02.2020 16:38, JiaTao Tao wrote:
> The detail message is as follows, and I can see LogicalSort and
> LogicalExchange has been generated though Expa
/core/src/test/java/org/apache/calcite/test/RelOptRulesTest.java#L6377
--
Kind Regards
Roman Kondakov
On 02.02.2020 08:01, JiaTao Tao wrote:
> Hi
> I wonder when will the exchange node be added to the execution plan. For
> example, In Spark, if a join is SMJ(SortMergeJoin), it
e previous
e-mails should be solved in the first place. We need first to make
Volcano optimizer work right and only then make some improvements like
search space pruning.
I would love to join this work to improve Volcano planner. Looking
forward for design doc.
--
Kind Regards
Roman Kondakov
O
@Haisheng, could you please clarify what you mean by these points?
> - the poor-design of column pruning,
> - lack of group properties etc.
I guess I'm not aware of these problems.
--
Kind Regards
Roman Kondakov
On 08.01.2020 02:21, Haisheng Yuan wrote:
>> @Haisheng, are you doi
I forgot to mention that this approach was inspired by Stamatis's idea [1]
[1]
https://ponymail-vm.apache.org/_GUI_/thread.html/d8f8bc0efd091c0750534ca5cd224f4dfe8940c9d0a99ce486516fd5@%3Cdev.calcite.apache.org%3E
--
Kind Regards
Roman Kondakov
On 07.01.2020 21:14, Roman Kondakov wrote
.ac.in/infolab/Data/Courses/CS632/Papers/Cascades-graefe.pdf
[3]
https://15721.courses.cs.cmu.edu/spring2019/papers/22-optimizer1/shapiro-ideas2001.pdf
[4] https://github.com/apache/calcite/pull/1732
--
Kind Regards
Roman Kondakov
On 07.01.2020 16:54, Haisheng Yuan wrote:
> It is still on m
ers. I guess N should be
relatively small here (N <= 3) because traits dimensionality is usually
small.
What do you think?
[1]
https://github.com/apache/calcite/blob/963a266d7b3859d141964217f4d16cae350b10e1/core/src/main/java/org/apache/calcite/plan/volcano/VolcanoPlanner.java#L675
--
Kind Regards
Roman Kondakov
of rules, as Drill does.
Also I'd like to mention that decoupling the logical planning from the
physical one looks
a bit weird to me because it violates the idea of Cascades framework.
Possibly this decoupling is the consequence of some performance issues.
--
Kind Regards
Roman Kondakov
-dev/201505.mbox/%3CCAAqfHNoQnr%2BeUVoH9nFxhB7FEDwdYAjV_Smq%3DY75fxsqGs66Yw%40mail.gmail.com%3E
--
Kind Regards
Roman Kondakov
46 matches
Mail list logo
