-
Notifications
You must be signed in to change notification settings - Fork 29.3k
[SPARK-58207][SQL] Skip pushdown for nondeterministic V2 filters #57357
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
peter-toth
wants to merge
4
commits into
apache:master
Choose a base branch
from
peter-toth:SPARK-58207-skip-pushdown-nondeterministic-v2-filters
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
Show all changes
4 commits
Select commit
Hold shift + click to select a range
125ec04
[SPARK-58207][SQL] Skip pushdown for nondeterministic V2 filters
peter-toth 8b03668
[SPARK-58207][SQL] Gate nondeterministic V2 filter pushdown behind a …
peter-toth b791dd7
Merge branch 'master' into SPARK-58207-skip-pushdown-nondeterministic…
peter-toth 76ebb97
[SPARK-58207][SQL] Reword 'must not' to 'should not' in nondeterminis…
peter-toth File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This does not make sense. This can suddenly break all connectors.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we absolutely need this, then some method on the
SupportsPushDownV2FiltersAPI would be OKish. That said, are we sure it is always safe to do, even in case of JDBC?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Each connector must decide this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What if the filter is used in multiple places and then it gets pushed in one connector scan and not the other? How do we ensure the pushed filter behaves exactly the same as the one we keep on the Spark side? Is it even safe to push down undeterministic conditions into any connectors?
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@aokolnychyi on "is it even safe to push a non-det condition into any connector?" — as I mentioned above, I think the answer is no, and not only because of partial-accept double-evaluation. Even if we (a) document a fully-accept-or-deny rule so nothing is evaluated twice, and (b) push the seed so the RNG sequence is identical, a full push can still change results.
Consider a filter with a translatable non-det predicate (say
rand() > 0.5) next to a non-translatable one (saymonotonically_increasing_id() < 100). Only the first gets pushed: it's forced down to the scan and evaluated first, over every scanned row, while the untranslatable one stays post-scan, over the survivors. Splitting and reordering two non-det predicates this way changes which rows the pushed one runs over, so the final result (and the semantics of the query) can differ. It's the same move the optimizer refuses to make elsewhere (CombineFilters,PushPredicateThroughNonJoin, etc. all gate ondeterministic).Given that, on the options:
pushDownNondeterministicPredicates) is the one I like least — it's a permanent public API that lets a connector keep depending on a behavior that isn't sound even for a fully-enforcing source. I'd rather not add it.So I'd like to land this either as-is (safe default + the legacy config as a temporary, deprecatable escape hatch) or with no flag at all (just never push). Either works for me — I'd just avoid the capability.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But the flag is not going to work. (If most connectors depend on new behavior, and suddenly we flip it)
One option is:
Or not even have a flag works for me as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's never the connector that depends on non-det pushdown. A connector just implements
SupportsPushDownV2Filtersand takes whatever Spark hands it. Gettingrand() > 0.5pushed in gains it nothing and isn't sound anyway, so no connector author would set apushDownNondeterministicPredicates()capability to true on purpose — it'd be dead API. The thing that can accidentally rely on the old behavior is a user's workflow that happened to get the results it wanted out of Spark's weird old behavior, and the person who knows about that workflow isn't the connector author.So the dependency lives at the query/session level, which is exactly where a
spark.sql.legacy.*conf belongs: flip the default to the correct behavior now, give the few who built on the old one a temporary, deprecatable switch. And flipping the default can't break a connector — keeping non-det filters post-scan only ever makes results more correct, never crashes a source, so it's purely opt-back-in.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds like we're converging on no flag. That's fine by me. If everyone's ok dropping the conf, I'll drop it tomorrow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@uros-b is it ok for JDBC connector, if next spark release does not push down non-deterministic filter? (if you work on this area before?)