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

Change first/last implementation to prevent redundant comparisons when data is already sorted #8678

Merged
merged 3 commits into from
Dec 30, 2023
Merged

Change first/last implementation to prevent redundant comparisons when data is already sorted #8678

merged 3 commits into from
Dec 30, 2023

Conversation

mustafasrepo
Copy link
Contributor

@mustafasrepo mustafasrepo commented Dec 29, 2023

Which issue does this PR close?

Closes #.

Rationale for this change

This is a follow up PR for PR8662. With the changes in this PR, first last aggregation does not make comparisons on its data when it is known that their input data already satisfies the ordering requirement.

What changes are included in this PR?

Are these changes tested?

Are there any user-facing changes?

@github-actions github-actions bot added physical-expr Physical Expressions sqllogictest SQL Logic Tests (.slt) labels Dec 29, 2023
@ozankabak ozankabak changed the title Change fist last implementation to prevent redundant computations Change first/last implementation to prevent redundant comparisons when data is already sorted Dec 29, 2023
Copy link
Contributor

@ozankabak ozankabak left a comment

Choose a reason for hiding this comment

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

I reviewed this in detail and it looks good to me. With this, FIRST/LAST functions get the best of both worlds: They make no comparison at all if their inputs are already sorted, but they can work with unsorted data too!

}

pub fn convert_to_last(self) -> LastValue {
let name = if self.name.starts_with("FIRST") {
Copy link
Contributor

Choose a reason for hiding this comment

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

case sensitive, or it comes upper case always?

Copy link
Contributor

Choose a reason for hiding this comment

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

AFAIK it always comes in uppercase.

@comphead comphead merged commit bb98dfe into apache:main Dec 30, 2023
22 checks passed
Copy link
Contributor

@alamb alamb left a comment

Choose a reason for hiding this comment

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

I love it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
physical-expr Physical Expressions sqllogictest SQL Logic Tests (.slt)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants