[
https://issues.apache.org/jira/browse/CALCITE-3879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17068154#comment-17068154
]
Haisheng Yuan commented on CALCITE-3879:
----------------------------------------
OK, I haven't seen the risk of generating rel id per query context for View and
MVs. I was thinking put rel id generator in RelOptCluster like {{nextCorrel}}.
How about ID generator being a thread local variable? Since Calcite is single
thread.
> Rel Id should be generated per query context instead of globally
> ----------------------------------------------------------------
>
> Key: CALCITE-3879
> URL: https://issues.apache.org/jira/browse/CALCITE-3879
> Project: Calcite
> Issue Type: Improvement
> Components: core
> Reporter: Haisheng Yuan
> Priority: Major
>
> The rel id will continue increasing until the class is unloaded. We have
> observed that the id is reaching 100 million after running for just several
> days. Although we don't use the id for calculation, it might be OK for
> integer overflow, but it doesn't make sense to generate unique id globally,
> it will hard to read the dumped plan and the rel id in the log, because the
> rel id is so large. IMO, the id should be generated per query context.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
