You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@calcite.apache.org by "Julian Hyde (JIRA)" <ji...@apache.org> on 2018/10/02 02:37:00 UTC

[jira] [Commented] (CALCITE-2471) RelNode description includes all tree when recomputed

    [ https://issues.apache.org/jira/browse/CALCITE-2471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16634855#comment-16634855 ] 

Julian Hyde commented on CALCITE-2471:
--------------------------------------

I considered creating a class that implements CharSequence but is composed of a list of CharSequences (any of which may be Strings). Its hashCode would be the same as the equivalent String. However, I never did it because if average string length is small then String will be a more efficient use of memory, and I think we're close to break-even. I might be wrong.

(Remember, this bug causes digests to get way larger than that should. When it is fixed, digest lengths will go back to under ~~100 chars on average.)

Having string digests - stored in the RelNode, not just computed on the fly - has been incredibly useful. I would not abandon that, but CharSequence would probably do just as well.

> RelNode description includes all tree when recomputed
> -----------------------------------------------------
>
>                 Key: CALCITE-2471
>                 URL: https://issues.apache.org/jira/browse/CALCITE-2471
>             Project: Calcite
>          Issue Type: Bug
>          Components: core
>            Reporter: Laurent Goujon
>            Assignee: Julian Hyde
>            Priority: Major
>
> The initial AbstractRelNode description is `{{typeName#id}}` but when recomputed, it includes all its inputs (and other attributes).
> When creating the final plan, HepPlanner visits each node bottom up, and recomputes the node digest. This causes node description to grow in size, up to the top node which contains basically a string copy of the whole tree. On large trees, this may consume a non-significant amount of memory.
> See email thread: https://lists.apache.org/thread.html/5e71c9f2b4e83865805841708f53471cfab1b5de673e6f162b68edc9@%3Cdev.calcite.apache.org%3E



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)