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

Minor: Simplify date_trunc code and add comments #6783

Merged
merged 1 commit into from
Jun 28, 2023

Conversation

alamb
Copy link
Contributor

@alamb alamb commented Jun 27, 2023

Which issue does this PR close?

Follow on to #6654 from @Weijun-H (❤️ )

Rationale for this change

While reviewing #6654 and trying to answer @viirya 's question here #6654 (comment)

What changes are included in this PR?

  1. Rename date_trunc_single to date_trunc_coarse to better explain what it does
  2. Add comments to explain how it works
  3. Remove the use of indirection and call the function directly

Are these changes tested?

Covered by the (very) nice existing tests added in #6654

Are there any user-facing changes?

No

@alamb alamb marked this pull request as ready for review June 27, 2023 21:11
@github-actions github-actions bot added the physical-expr Physical Expressions label Jun 27, 2023
let Some(nano) = (f)(Some(value * scale))? else {
return Ok(None);
};
let nano = date_trunc_coarse(granularity, scale * value)?;
Copy link
Contributor Author

Choose a reason for hiding this comment

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

There is no need for a closure, and the function can be called directly which I think makes things easier to understand

Copy link
Contributor Author

@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.

Copy link
Contributor Author

@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.

The date_trunc code could be quite a bit faster if it did not check the granularity on each row but instead did that once per column. That can be an optimization for some later time

@@ -214,7 +214,11 @@ fn quarter_month(date: &NaiveDateTime) -> u32 {
1 + 3 * ((date.month() - 1) / 3)
}

fn date_trunc_single(granularity: &str, value: i64) -> Result<i64> {
/// Tuncates the single `value`, expressed in nanoseconds since the
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think this is correct -- @Weijun-H does it match your understanding?

Copy link
Member

Choose a reason for hiding this comment

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

Nice simplification 👍 !

@alamb alamb merged commit 0a4714d into apache:main Jun 28, 2023
@alamb alamb deleted the alamb/comments2 branch June 28, 2023 18:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
physical-expr Physical Expressions
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants