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

Julian Hyde commented on CALCITE-4994:
--------------------------------------

[~jaynarale], You're right. My version that had {{MapBackedList}} wasn't 
faster. I'm not sure why; maybe the {{instanceof}} check was slow.

Please see 
[e185e01e|https://github.com/julianhyde/calcite/commit/e185e01e1cded7333486a2f0a93161a83cabfbe3],
 "Add fieldMap in RelRecordType; SqlToRelConverter.Blackboard.lookupExp now 
returns BiFunction". When I run the {{convertToRel}} benchmark it is as fast as 
your "Map a blackboard" change. It is potentially the best change, because it 
will improve performance throughout the preparation process.

> SqlToRelConverter creates FieldMap for every Identifier Instead of Memoizing 
> it
> -------------------------------------------------------------------------------
>
>                 Key: CALCITE-4994
>                 URL: https://issues.apache.org/jira/browse/CALCITE-4994
>             Project: Calcite
>          Issue Type: Improvement
>          Components: core
>            Reporter: Jay Narale
>            Priority: Major
>              Labels: pull-request-available
>          Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> When converting from Sql To Rel, In SqlToRelConverter for every single 
> instance of an identifier we create a new map in 
> *_org.apache.calcite.sql2rel.SqlToRelConverter.Blackboard#lookupExp_*
>  
> {code:java}
> final Map<String, Integer> fieldOffsets = new HashMap<>();
> for (RelDataTypeField f : resolve.rowType().getFieldList()) {
> if (!fieldOffsets.containsKey(f.getName())) {
> fieldOffsets.put(f.getName(), f.getIndex());
> }
> }
> final Map<String, Integer> map = ImmutableMap.copyOf(fieldOffsets);{code}
>  
> So for a Sql Query
> {code:java}
> SELECT name, nation FROM customer{code}
> We would do the above operation twice.
> Memoization of this information will improve performance.
> In my database, I had observed that for a large table involving 1200 columns 
> and a huge select having multiple expressions and operators, this part was a 
> bottleneck.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

Reply via email to