You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hive.apache.org by "Krisztian Kasa (Jira)" <ji...@apache.org> on 2026/07/09 16:31:00 UTC
[jira] [Assigned] (HIVE-29525) Iceberg partitioned columns are not reflected by RelOptHiveTable
[ https://issues.apache.org/jira/browse/HIVE-29525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Krisztian Kasa reassigned HIVE-29525:
-------------------------------------
Assignee: Krisztian Kasa
> Iceberg partitioned columns are not reflected by RelOptHiveTable
> ----------------------------------------------------------------
>
> Key: HIVE-29525
> URL: https://issues.apache.org/jira/browse/HIVE-29525
> Project: Hive
> Issue Type: Bug
> Components: CBO
> Reporter: Stamatis Zampetakis
> Assignee: Krisztian Kasa
> Priority: Major
>
> Iceberg partitioned columns are not reflected by RelOptHiveTable and the respective data-structures (hivePartitionCols and hivePartitionColsMap) are always empty. RelOptHiveTable is used in various places during the CBO planning phase so any logic that depends on partitioning information is not kicking in and all Iceberg tables are treated as unpartitioned.
> Depending on the context where the partitioning information is used different issues may arise. For instance, selectivity estimation is computed differently if the predicate is over a partitioning column (see [FilterSelectivityEstimator|https://github.com/apache/hive/blob/931d4bb62b26de699240c816df439e00644e3dcb/ql/src/java/org/apache/hadoop/hive/ql/optimizer/calcite/stats/FilterSelectivityEstimator.java#L105]) so the absence of partitioning information can have a direct impact on cardinality (row count) estimations and affect join order.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)