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

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

                Author: ASF GitHub Bot
            Created on: 09/Nov/21 14:19
            Start Date: 09/Nov/21 14:19
    Worklog Time Spent: 10m 
      Work Description: scarlin-cloudera commented on a change in pull request 
#2763:
URL: https://github.com/apache/hive/pull/2763#discussion_r745659469



##########
File path: 
ql/src/java/org/apache/hadoop/hive/ql/optimizer/calcite/RelOptHiveTable.java
##########
@@ -333,12 +360,20 @@ public boolean isKey(ImmutableBitSet columns) {
           parentTableQualifiedName.add(parentTableName);
           qualifiedName = parentTableName;
         }
+        if (!tablesCache.containsKey(qualifiedName)) {
+          // Table doesn't exist in the cache, so we don't need to track
+          // these referential constraints. But we do need to keep track
+          // of the table in case the tableCache gets populated later, though
+          // in theory, this should never happen based on how this is called.

Review comment:
       Here's the reason why I did it this way:
   
   RelOptHiveTable takes in a hash map containing the table name with the table 
object.  In my perfect world of coding, this hash map would be immutable.  It 
makes coding much easier when the objects are static at initialization time.
   
   This is the proper way to code it, in my opinion.  That would make this test 
unnecessary.
   
   However, this hash map can't be immutable because it is being populated 
while each RelOptHiveTable is being constructed.  
   
   Once this code is rewritten, we can then remove this extra code.  But I 
think defensive coding here is best.  By coding it this way, the 
RelOptHiveTable will stay internally consistent no matter how it is called, 
while that table hash map stays mutable. 




-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: gitbox-unsubscr...@hive.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


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

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

> Avoid getTable() calls for foreign key tables not used in a query
> -----------------------------------------------------------------
>
>                 Key: HIVE-25670
>                 URL: https://issues.apache.org/jira/browse/HIVE-25670
>             Project: Hive
>          Issue Type: Improvement
>          Components: HiveServer2
>            Reporter: Steve Carlin
>            Priority: Major
>              Labels: pull-request-available
>          Time Spent: 50m
>  Remaining Estimate: 0h
>
> In RelOptHiveTable, we generate the referential constraints for the table. In 
> this process, we make a metastore call to fetch these tables.  This is used 
> later on for potential gain on joins done on the key.
> However, there is no need to fetch these constraints if the table is not used 
> in the query. If we can get this information up front, we can save a bit on 
> compilation time.
>  



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

Reply via email to