Jiatao Tao created CALCITE-3770:
---
Summary: Minor change "EnumerableCalcRel" to "EnumerableCalcRel"
Key: CALCITE-3770
URL: https://issues.apache.org/jira/browse/CALCITE-3770
Project: Calcite
The Apache Jenkins build system has built Calcite-Master (build #1593)
Status: Failure
Check console output at https://builds.apache.org/job/Calcite-Master/1593/ to
view the results.
Hi Rui. Julian
Thanks for your reply
Volcano/Cascade is greate(Rules do not affect each other). The problem is
the estimated cost does really help, particularly in big data?
The estimates may be inaccurate, like this "JOIN-FILTER-TABLSCAN", we
estimate that the filtering rate is large and chose
Danny Chen created CALCITE-3769:
---
Summary: Deprecate TableScanRule
Key: CALCITE-3769
URL: https://issues.apache.org/jira/browse/CALCITE-3769
Project: Calcite
Issue Type: Wish
The TableScanRule is the only planner rule that for a logical node(e.g. the
table scan), it’s functionality is to pass along the cluster object and invoke
the RelOptTable#toRel. It’s function is very trivial because it supplies only a
ToRelContext that does not support expanding view/passing
Xiening Dai created CALCITE-3768:
Summary: VolcanoPlanner.changeTraitsUsingConverters() has
parameter that's never used
Key: CALCITE-3768
URL: https://issues.apache.org/jira/browse/CALCITE-3768
Runtime optimization is important too. Examples include the DB’s buffer cache
(predicting future disk accesses based on previous accesses using e.g. LRU2)
and self-tuning algorithms such as hybrid hash join (which figures out what key
to use to partition, and which side of a join to build,
>From some real world practice I have heard (but we haven't tried it in
BeamSQL yet), CBO becomes bad as the complexity of plan increases as
estimation will be hard to be close to reality in the later stages for big
data processing. Instead, the runtime optimization that you called out,
does
Under big data, does CBO have such a big effect?
Node like filter/join/aggregate, their cost is estimated.
There's one case, I call it runtime optimizing, it means optimizing while c
alculating, You adjust your execution plan in real-time based on the
execution statistics of the previous
Thank you for your patience, really appreciate it!
Regards!
Aron Tao
Roman Kondakov 于2020年2月4日周二 下午5:21写道：
> Hi Aron,
>
> > 1. It seems in Calcite's main query process(via Prepare#prepareSql)
> > there's no code to `addRelTraitDef(RelDistributionTraitDef.INSTANCE)`,
> > and even no config,
The TableScanRule is the only planner rule that for a logical node(e.g. the
table scan), it’s functionality is to pass along the cluster object and invoke
the RelOptTable#toRel. It’s function is very trivial because it supplies only a
ToRelContext that does not support expanding view/passing
Vladimir Sitnikov created CALCITE-3767:
--
Summary: AssertionError when SqlBinaryStringLiteral appears in
tablesample substitute
Key: CALCITE-3767
URL: https://issues.apache.org/jira/browse/CALCITE-3767
Hi Aron,
> 1. It seems in Calcite's main query process(via Prepare#prepareSql)
> there's no code to `addRelTraitDef(RelDistributionTraitDef.INSTANCE)`,
> and even no config, anyone know why?
AFAIK distributed systems that use Calcite as a Query optimizer (like
Drill, Flink, Ignite, etc) usually
Hi Aron,
>From what I understand by looking into RelDistributionImpl class is that it
accepts the keys/columns on which the hash function is applied.
Given the properties of a hash function, I would say that this information
is sufficient for determining if a collocated join is possible.
I don't
14 matches
Mail list logo
