[jira] [Comment Edited] (CALCITE-3167) Remove overriding equals and hashCode methods in EnumerableTableScan

["jin xing (JIRA)" <ji...@apache.org>]

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

jin xing edited comment on CALCITE-3167 at 7/3/19 1:28 PM:
-----------------------------------------------------------

Thanks a lot for reply [~julianhyde]
 # I also think it's a good idea to prohibit overriding {{equals}} and {{hashCode}} for {{RelNode}} and users should define the identity case by case;
 # As for overriding {{equals}} and {{hashCode}} in {{AbstractRelNode}} and making them final, how about implement by {{digest ?}} i.e. {{RelNodes}} equals with each other when they have the same {{digests}} and we generate {{hashCode}} of {{RelNode}} by {{digest}}'s {{hashCode}}. User should guarantee that all key information should be included in {{digest}}
 # I think the idea in CALCITE-1216 is straightforward. Before that change, 'materialization-substitution' only happens at the very start of {{findBestExp}}. After the change, {{MaterializedViewFilterScanRule.java does}} the materialization-substitution during running optimization-rules. Thus query plan has a  chance to be 'normalized' after some optimization rules and then get optimized by materialization-substitution. This might introduce extra cost since the materialization-substitution tends to be a heavy process. 
 # Digging the code, I did't find any necessity for the {{overrides}} in {{EnumerableScan}}. After removing them, I passed all the tests. I think existing tests are sufficient. Because {{EnumerableTableScanRule}} will create a new EnumerableTableScan every time it meets a LogicalTableScan, i.e. {{query}} and {{materialization}} don't share the same Java object for table-scan.


was (Author: jinxing6042@126.com):
Thanks a lot for reply [~julianhyde]
 # I also think it's a good idea to prohibit overriding {{equals}} and {{hashCode}} for {{RelNode}} and users should define the identity case by case;
 # As for overriding {{equals}} and {{hashCode}} in {{AbstractRelNode}} and making them final, how about implement by {{digest ?}} i.e. {{RelNodes equals with each other when they have the same}} {{digests}} and we generate {{hashCode}} of {{RelNode}} by {{digest}}'s {{hashCode}}. User should guarantee that all key information should be included in {{digest}}
 # I think the idea in CALCITE-1216 is straightforward. Before that change, 'materialization-substitution' only happens at the very start of {{findBestExp}}. After the change, {{MaterializedViewFilterScanRule.java does}} the materialization-substitution during running optimization-rules. Thus query plan has a  chance to be 'normalized' after some optimization rules and then get optimized by materialization-substitution. This might introduce extra cost since the materialization-substitution tends to be a heavy process. 
 # Digging the code, I did't find any necessity for the {{overrides}} in {{EnumerableScan}}. After removing them, I passed all the tests. I think existing tests are sufficient. Because {{EnumerableTableScanRule}} will create a new EnumerableTableScan every time it meets a LogicalTableScan, i.e. {{query}} and {{materialization}} don't share the same Java object for table-scan.

> Remove overriding equals and hashCode methods in EnumerableTableScan
> --------------------------------------------------------------------
>
>                 Key: CALCITE-3167
>                 URL: https://issues.apache.org/jira/browse/CALCITE-3167
>             Project: Calcite
>          Issue Type: Improvement
>          Components: core
>    Affects Versions: 1.19.0
>            Reporter: jin xing
>            Priority: Minor
>              Labels: pull-request-available
>          Time Spent: 20m
>  Remaining Estimate: 0h
>
> In current code of {{EnumerableTableScan}}, methods of equals and hashCode are overridden for matching of {{EnumerableTableScan}}s.
> While after optimizing with the same HEP planner, {{EnumerableTableScan}}s from two plans but with the same digest will the share the same Java object. See [RelOptMaterializations|https://github.com/apache/calcite/blob/adf4cc4dc5cdb9f5e49c85d10f46a2fdcd831ccf/core/src/main/java/org/apache/calcite/plan/RelOptMaterializations.java#L192].
> I think it's ok to remove the redundant overriding methods in {{EnumerableTableScan}}.



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