Skip to content

Conversation

@viirya
Copy link
Member

@viirya viirya commented Feb 9, 2020

What changes were proposed in this pull request?

We prune nested fields from Generate. If a child output is required in a top operator of Generate, we should not prune nested fields on it. Otherwise, the accessors on top operator could be unresolved.

Why are the changes needed?

A required child output means it is referred as a whole or by its nested fields on top of operator of Generate. If the rule prunes other nested fields from it, the accessors on top operator will be unresolved.

Does this PR introduce any user-facing change?

No.

How was this patch tested?

Unit tests.

Comment on lines +190 to +191
val requiredAttrs = AttributeSet(g.requiredChildOutput)
NestedColumnAliasing.getAliasSubMap(g.generator.children, requiredAttrs).map {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This case normally should be treated by above case pattern (Project + Generate). But if all nested fields are selected at top Project, the above case won't prune. Then when Optimizer transforms down to the underlying Generate, only the referred nested column are kept and others are pruned from the child. It causes the accessors at top Project unresolved.

}

testSchemaPruning("select explode of nested field of array of struct and " +
"all remaining nested fields") {
Copy link
Member

@gatorsmile gatorsmile Feb 9, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of fixing case by case, can we try to find all the possible cases and ensure we can cover all the possible query plans? Includes negative and positive cases.

Also, we need to have the unit test cases for these optimizer rules.

@gatorsmile
Copy link
Member

If a child output is required in a top operator of Generate, we should not prune nested fields on it. Otherwise, the accessors on top operator could be unresolved.

Do we traverse all the ancestor nodes?

@gatorsmile gatorsmile closed this Feb 9, 2020
@gatorsmile gatorsmile reopened this Feb 9, 2020
@gatorsmile
Copy link
Member

@viirya How about reverting the original commit a0e63b6 and then consider how to improve the rule?

@viirya
Copy link
Member Author

viirya commented Feb 9, 2020

@gatorsmile I'm ok to revert it.

@viirya viirya closed this Feb 9, 2020
@SparkQA
Copy link

SparkQA commented Feb 9, 2020

Test build #118085 has finished for PR 27503 at commit 2e2302f.

  • This patch fails due to an unknown error code, -9.
  • This patch merges cleanly.
  • This patch adds no public classes.

@viirya viirya deleted the fix-generate-pruning branch December 27, 2023 18:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants