-
Notifications
You must be signed in to change notification settings - Fork 968
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
project_column_with_filters_that_cant_pushed_down_always_true
only passes if plan is optimized twice
#3283
Comments
This is interesting, if you haven't already started @andygrove I'd like to take a look at it (by initially fixing the underlying bug in the test and then fixing the test logic). |
This is a really interesting aspect of optimizer rules I've encountered before, and am not sure how to best address:
I'm curious how other optimizers handle this. |
Aside from the point @avantgardnerio shared (regarding how new optimizations could be uncovered after different passes, which I would think deserves its own issue), the problem here might be a little bit different. Something particular I noticed was that, when |
Yes, we should file a ticket to discuss this -- I'll try if no one else beats me to it
I have worked on systems in the past where the order was hard coded. Someone I know from the spark team says it runs until it reaches a "fixed point" (aka until running it doesn't change the plans). I think this is also an interesting question the context of constant evaluation / expression simplification |
Describe the bug
In
execute_to_batches
, we create the physical plan from an optimized logical plan. This results in the plan being optimized twice. Fixing this causes a regression inproject_column_with_filters_that_cant_pushed_down_always_true
.To Reproduce
Modify
execute_to_batches
to pass the unoptimized logical plan tocreate_physical_plan
.Expected behavior
Test should pass
Additional context
None
The text was updated successfully, but these errors were encountered: