Skip to content
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

Physical optimizers cannot rewrite HashJoinExec due to join_schema being private #12806

Closed
progval opened this issue Oct 8, 2024 · 0 comments · Fixed by #12807
Closed

Physical optimizers cannot rewrite HashJoinExec due to join_schema being private #12806

progval opened this issue Oct 8, 2024 · 0 comments · Fixed by #12807
Labels
enhancement New feature or request

Comments

@progval
Copy link
Contributor

progval commented Oct 8, 2024

Is your feature request related to a problem or challenge?

HashJoinExec internally performs a projection, which is exposed through the public HashJoinExec::projection field. However, this field is a Option<Vec<usize>>, where each item in the vector is an index in HashJoinExec::join_schema, which is not public.

This means the projection performed by HashJoinExec is not available to physical optimizers (though they might be able to infer it from the left().schema() and right.schema()? this seems error-prone at best)

Describe the solution you'd like

Either:

  1. make HashJoinExec::join_schema public
  2. decouple projection HashJoinExec

Describe alternatives you've considered

Provide a way for library users to define their own logical_expr::Join -> ExecutionPlan compiler, so they don't need a physical optimizer to do it.

(If there is already a way to do it, then I missed it.)

Additional context

No response

@progval progval added the enhancement New feature or request label Oct 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant