Behavioral changes in Apache Hive

Learn about the change in certain functionality of Hive that has resulted in a change in behavior from the previously released version to this version of Cloudera Runtime.

Summary:: Change in default value of the hive.optimize.sort.dynamic.partition.threshold property; Previous behavior:; The default value for the hive.optimize.sort.dynamic.partition.threshold property is set to "-1"; New behavior:; The default value for the hive.optimize.sort.dynamic.partition.threshold property is changed to "0" to enable cost-based optimization for dynamic partitioning and address performance issues while bulk loading data into Hive tables.
important
Due to HIVE-26283, it is noticed that some queries that were running normally (with the default value of "-1") in the previous version of Cloudera Runtime are now taking longer to complete or fail entirely (usually noticed in large clusters).
As a workaround, you can revert the value of hive.optimize.sort.dynamic.partition.threshold to "-1" either at the query session level or in hive-site.xml using the Cloudera Manager Safety Valve.
For queries that ran in the previous version with the value set to "0" or "1" (optimization enabled), you do not have to modify the default value after upgrading to Cloudera Runtime 7.1.7 SP1 and the queries will continue to run normally.
Summary:: Changes to Locking Behavior for External Tables; Previous behavior:; External tables were supported with locking.; New behavior:; Starting with CDP 7.1.7 SP1 CHF 11, Hive no longer places locks on external tables by default. To enable lock support for external tables in CDP, set hive.txn.ext.locking.enabled to true at the cluster level, as per HIVE-26258.