[ 
https://issues.apache.org/jira/browse/HIVE-27238?focusedWorklogId=859871&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-859871
 ]

ASF GitHub Bot logged work on HIVE-27238:
-----------------------------------------

                Author: ASF GitHub Bot
            Created on: 01/May/23 14:32
            Start Date: 01/May/23 14:32
    Worklog Time Spent: 10m 
      Work Description: scarlin-cloudera commented on PR #4212:
URL: https://github.com/apache/hive/pull/4212#issuecomment-1529778518

    @zabetak : I'm not sure what is meant by a micro-benchmark.  Can you 
explain what is needed here or provide an example from a previous commit?
    
    As for not being thread-safe: Not sure what you mean here.  The "get" is 
wrapped in a "synchronized" call.  I don't think the underlying Calcite classes 
will have any thread safety issues when I did the code inspection within 
Calcite, but admittedly, I'm not a Calcite expert.
    
    But without this code (as I hope to show with the micro-benchmarks 
perhaps), we are regenerating Calcite classes which they specifically try to 
avoid.  It does add to the compile time as I have seen through my own private 
benchmarks.
    
   I do realize this is risky though.  Do we have any framework within Hive 
that does concurrency testing? If not, perhaps that is something I should 
consider adding.
   




Issue Time Tracking
-------------------

    Worklog Id:     (was: 859871)
    Time Spent: 50m  (was: 40m)

> Avoid Calcite Code generation for RelMetaDataProvider on every query
> --------------------------------------------------------------------
>
>                 Key: HIVE-27238
>                 URL: https://issues.apache.org/jira/browse/HIVE-27238
>             Project: Hive
>          Issue Type: Improvement
>          Components: HiveServer2
>            Reporter: Steve Carlin
>            Priority: Major
>              Labels: pull-request-available
>          Time Spent: 50m
>  Remaining Estimate: 0h
>
> In CalcitePlanner, we are instantiating a new CachingRelMetadataProvider on 
> every query.  Within the Calcite code, they keep the provider key to prevent 
> a new MetadataHandler class from being created.  But by generating a new 
> provider, the cache never gets a hit so we keep instantiating new 
> MetadataHandlers.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to