Skip to content

Conversation

@alamb
Copy link
Contributor

@alamb alamb commented Sep 29, 2025

Which issue does this PR close?

Rationale for this change

I feel like the impl AsRef<T> for T pattern isn't great, so I would like to try and avoid it unless there is no other way

For example, @findepi has proposed adding it here

What changes are included in this PR?

Change signatures of functions that take &[Expr] (owned expressions) to take an iterator of &Expr which is what they need

Are these changes tested?

By CI

Are there any user-facing changes?

@github-actions github-actions bot added the optimizer Optimizer rules label Sep 29, 2025
@alamb alamb mentioned this pull request Sep 29, 2025
.map_or_else(Vec::new, |filter| split_conjunction_owned(filter.clone()));
.map_or_else(Vec::new, |filter| split_conjunction(filter));

let predicates: Vec<Expr> = predicates.into_iter().cloned().collect();
Copy link
Contributor

Choose a reason for hiding this comment

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

Thanks @alamb

cloned() on iter calls a clone under the hood for each element?

https://doc.rust-lang.org/beta/std/iter/trait.Iterator.html#method.cloned

I'm trying to figure out the benefit

Copy link
Member

Choose a reason for hiding this comment

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

The split_conjunction_owned -> split_conjunction change above avoids cloning the pred components.
But any benefit seems to be indeed voided by cloning here, which we execute unconditionally.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sorry I should have been clearer.

This code is splitting an expresision like

AND
  AND
    expr1
    expr2
  expr3

The cloned call still clones expr1, expr2, and expr3 but it doesn't clone the ANDs.

However, I agree that the benefit seems minor - I was more interested in alternate approaches than defining AsRef for Expr #17819

#17819 also included this improvement and I wanted to show it was also possible in another way too

I am happy to close this PR too

@alamb
Copy link
Contributor Author

alamb commented Sep 30, 2025

Let's go with #17819

@alamb alamb closed this Sep 30, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

optimizer Optimizer rules

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants