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

feat(batch): support as of now() - interval for time travel #17665

Merged
merged 7 commits into from
Jul 12, 2024

Conversation

zwang28
Copy link
Contributor

@zwang28 zwang28 commented Jul 11, 2024

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.

What's changed and what's your intention?

This PR supports the syntax FOR SYSTEM TIME AS OF NOW() - INTERVAL for time travel query.

  • To differentiate from temporal join's AS OF NOW/PROCTIME, time travel uses AS OF CURRENT.
  • The existing Interval parser is being reused. Time travel query restricts the interval to be value + unit.

It also adds e2e tests for time travel query.

Checklist

  • I have written necessary rustdoc comments
  • I have added necessary unit tests and integration tests
  • I have added test labels as necessary. See details.
  • I have added fuzzing tests or opened an issue to track them. (Optional, recommended for new SQL features Sqlsmith: Sql feature generation #7934).
  • My PR contains breaking changes. (If it deprecates some features, please create a tracking issue to remove them in the future).
  • All checks passed in ./risedev check (or alias, ./risedev c)
  • My PR changes performance-critical code. (Please run macro/micro-benchmarks and show the results.)
  • My PR contains critical fixes that are necessary to be merged into the latest release. (Please check out the details)

Documentation

  • My PR needs documentation updates. (Please use the Release note section below to summarize the impact on users)

Release note

Support time travel query to access historical data at a specific points in time.

@zwang28 zwang28 requested a review from a team as a code owner July 11, 2024 14:18
@zwang28 zwang28 requested review from MrCroxx, hzxa21 and chenzl25 July 11, 2024 14:18
@zwang28 zwang28 force-pushed the wangzheng/time_travel_2 branch 3 times, most recently from c92904b to 58b87a5 Compare July 11, 2024 14:47
@zwang28 zwang28 force-pushed the wangzheng/time_travel_2 branch from c7d9565 to 9210ca4 Compare July 11, 2024 15:21
Comment on lines 3156 to 3157
// used by time travel
ProcessTimeWithInterval((String, Option<DateTimeField>)),
Copy link
Contributor

Choose a reason for hiding this comment

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

Should we evaluate ProcessTimeWithInterval to TimestampNum at the parser? In this way, we can unify the code.

Copy link
Contributor Author

@zwang28 zwang28 Jul 12, 2024

Choose a reason for hiding this comment

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

I've also considered that once.
The issue is the Interval parser is not in sqlparser crate. Not sure if it's a good idea to move this Interval parser to sqlparser crate, because it'll introduce additional dependencies to sqlparser crate.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It's similar to why we don't evaludate AsOf::TimestampString to AsOf::TimestampNum.

Copy link
Contributor

Choose a reason for hiding this comment

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

I see. ProcessTimeWithInterval((String, Option<DateTimeField>)), this enum looks a bit special because it only can represent an expression like CURRENT() - xxx but not another form. Can we use an expression instead, so that we can support a more general expression like CURRENT() + xxx - yyy

Copy link
Contributor

Choose a reason for hiding this comment

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

For example, this sql select now() - interval '1' Day + interval '2' hour; could be evaluated to a const 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.

As discussed offline, using expr as a better idea, can be done in further PR.

@zwang28 zwang28 requested a review from chenzl25 July 12, 2024 03:36
Copy link
Contributor

@chenzl25 chenzl25 left a comment

Choose a reason for hiding this comment

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

Rest LGTM

preceded(
(
Self::parse_identifier
.verify(|ident| ident.real_value() == "current"),
Copy link
Contributor

Choose a reason for hiding this comment

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

Let's use now() instead of current(), since now() could be used in the batch query directly and process time temporal join is no longer using now as key word.

@zwang28 zwang28 enabled auto-merge July 12, 2024 07:46
@zwang28 zwang28 changed the title feat(batch): support as of current - interval for time travel feat(batch): support as of now() - interval for time travel Jul 12, 2024
@zwang28 zwang28 disabled auto-merge July 12, 2024 07:48
@zwang28 zwang28 enabled auto-merge July 12, 2024 08:06
Copy link
Contributor

@MrCroxx MrCroxx left a comment

Choose a reason for hiding this comment

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

LGTM for the Cargo.lock.

@zwang28 zwang28 added this pull request to the merge queue Jul 12, 2024
Merged via the queue into main with commit d06bb47 Jul 12, 2024
30 of 31 checks passed
@zwang28 zwang28 deleted the wangzheng/time_travel_2 branch July 12, 2024 09:10
zwang28 added a commit that referenced this pull request Jul 14, 2024
@zwang28 zwang28 added the user-facing-changes Contains changes that are visible to users label Jul 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants