[WIP]

[ramitg254]

What changes were proposed in this pull request?

Why are the changes needed?

Does this PR introduce any user-facing change?

How was this patch tested?

[deniskuzZ]

@ramitg254 please take a look: 9e7535c. I would suggest following similar approach

[ramitg254]

9e7535c

but here we are creating separate method getEffectivePartCols() and leaving getPartCols() as it is, which as per our discussion on that closed pr we shouldn't do that, and only go ahead with updating getPartCols()

[deniskuzZ]

9e7535c

but here we are creating separate method getEffectivePartCols() and leaving getPartCols() as it is, which as per our discussion on that closed pr we shouldn't do that, and only go ahead with updating getPartCols()

Where did I say that? The ask was to keep the original method unchanged. same here

[ramitg254]

oh I got confused due to this comment: #6337 (comment) in which getSupportedPartCols() was just separate method similar to getEffectivePartCols()

[ramitg254]

I am fine with that earlier approach as well but recently I saw this one: https://issues.apache.org/jira/browse/HIVE-29525 so I thought we should have unified getPartCols() and getCols() which gives similar results as native hive tables as first step towards solving this after that those plan logics can be taken care of later on when that ticket will be addressed.
So I was first focussing on making getPartCols() unified for iceberg tables as well.

please share your thoughts on this idea

[deniskuzZ]

I am fine with that earlier approach as well but recently I saw this one: https://issues.apache.org/jira/browse/HIVE-29525 so I thought we should have unified getPartCols() and getCols() which gives similar results as native hive tables as first step towards solving this after that those plan logics can be taken care of later on when that ticket will be addressed. So I was first focussing on making getPartCols() unified for iceberg tables as well.

please share your thoughts on this idea

I also tried unified getPartCols(), but that ended up requiring column deduplication or adding supportNonNativePart in several places. So effectivePartCol was more of a cleaner workaround.

That said, you’re right—we might be missing some optimizations with the new method. If you’re already looking into it, maybe try getting everything working with a single getPartCols() first. That way you can identify all the spots that need adjustments (re-enable optimizations), and then switch back to the effectivePartCol API and drop those interim patches.

[sonarqubecloud]

Quality Gate passed

Issues
2 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.8% Duplication on New Code

See analysis details on SonarQube Cloud