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

Jay Narale commented on CALCITE-4994:
-------------------------------------

[~julianhyde] . Basically here we want to find the index of the current 
Identifier. The lamda will be better than popultating the map but

will still need to be evaluated each time for all *qualified.suffix()* where it 
is used ({_}e0.right{_}  Not sure how often qualified.suffix() returns an array 
length > 1). 

Also we still would need to do the computation each time for all identifiers as 
each identifier is converted separately.

If we store this information ( mapping of name to Id) in namespace , or 
evaluate all the identifiers together it would be the best but doesn't look 
feasible. 

 

 

 

> 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