[
https://issues.apache.org/jira/browse/IMPALA-13882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joe McDonnell resolved IMPALA-13882.
------------------------------------
Fix Version/s: Impala 5.0.0
Resolution: Fixed
> Iceberg deletes don't work with tuple caching
> ---------------------------------------------
>
> Key: IMPALA-13882
> URL: https://issues.apache.org/jira/browse/IMPALA-13882
> Project: IMPALA
> Issue Type: Bug
> Components: Backend
> Affects Versions: Impala 5.0.0
> Reporter: Joe McDonnell
> Assignee: Joe McDonnell
> Priority: Critical
> Fix For: Impala 5.0.0
>
>
> Comparing enable_tuple_cache=false to enable_tuple_cache=true shows that
> tuple caching hits an error for Iceberg tables with deletes.
> Examples:
> {noformat}
> set enable_tuple_cache=false;
> [localhost:21050] functional_parquet> select * from
> iceberg_v2_positional_update_all_rows;
> +---+---+
> | i | s |
> +---+---+
> | 1 | A |
> | 2 | B |
> | 3 | C |
> +---+---+
> Fetched 3 row(s) in 0.11s
> set enable_tuple_cache=true;
> [localhost:21050] functional_parquet> select * from
> iceberg_v2_positional_update_all_rows; 2025-03-20 13:31:53 [Exception]
> ERROR: Query 054e755acc4622e2:702eca1400000000 failed:
> Failed to find file to hosts mapping for plan node: 9{noformat}
> One theory is that some logic can depend on the scan node being the immediate
> child of the delete node. Tuple caching can insert a TupleCacheNode in
> between, so maybe the logic wasn't built to handle that case. We should add
> tests of various Iceberg scenarios with tuple caching.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
