[
https://issues.apache.org/jira/browse/IGNITE-12248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16981405#comment-16981405
]
Roman Kondakov commented on IGNITE-12248:
-----------------------------------------
[~gvvinblade], I've taken a look to your approach and overall it seems to be
very good.
I just have a list of minor questions:
# Why do we need spring dependencies in calcite/pom.xml?
# Are we going to support {{_key}} and {{_val}} columns in the new engine? Why?
# Why do we use java serialization in calcite.serialize package?
# What is the purpose of {{CalciteSchemaHolder}}? Why don't use just
{{RootSchema}}? I haven't got the idea.
# Why do we need {{IgnitePlanner}}? It is almost certain copy of
{{org.apache.calcite.prepare.PlannerImpl}}
# Why do we wrap everything into {{Context}}? Even query itself. Do we really
need it? See {{CalciteQueryProcessor#context()}}. Excessive use of
wrap/unwrap/chaining/etc methods affects code readablity.
# Looks like {{RelOp}} interface is redundant. Also as usage of {{BiFunction}}
in {{Commons#transformSubset}}. IMO we need to avoid excessive using of lambdas
and functions. It affects readability too.
# Why do we need to have {{DistributionRegistry}}? Aren't tables aware of
their distributions?
# IgniteMdDistribution#join - there is a list of differnet types of joins and
there is also a statement that "others are impossible". Why broadcast LEFT JOIN
hash is impossible?
# What is the difference between implementor and visitor? See
{{RelImplementor}}. If there are no differences, why don't use the word
{{Visitor}} instead of {{Implementor}} just because it is the well known
pattern?
> Apache Calcite based query execution engine
> -------------------------------------------
>
> Key: IGNITE-12248
> URL: https://issues.apache.org/jira/browse/IGNITE-12248
> Project: Ignite
> Issue Type: Task
> Components: sql
> Reporter: Igor Seliverstov
> Assignee: Igor Seliverstov
> Priority: Major
>
> Currently used H2 based query execution engine has a number of critical
> limitations Which do not allow to execute an arbitrary query.
> The ticket aims to show potential of a new, Calcite based, execution engine
> which may act not worse than current one on co-located queries, provide a
> boost for queries, using distributed joins, and provide an ability to execute
> arbitrary queries, requiring more than one map-reduce step in execution flow.
> [IEP
> link|https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=130028084]
> [Dev list
> thread|http://apache-ignite-developers.2346864.n4.nabble.com/New-SQL-execution-engine-td43724.html]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
