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

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

I added a few commits to your PR in 
[julianhyde/4994-slow-field-lookup|https://github.com/julianhyde/calcite/tree/4994-slow-field-lookup].
 I think that if we can build the map inside the RelDataType then it will have 
the right lifecycle (avoiding staleness and memory bloat) and will speed up 
code that needs to lookup field names that is not just in SqlToRelConverter.

I needed a threshold below which building the map would not save us any time, 
and I guessed 20.

What do you think?

> 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