ESQL: TSTEP #1

[sidosera]

Small refactoring to handle time patterns needed for TBUCKET/TSTEP bucketing.

Issue: #139187

Stack:

• ESQL: TSTEP #1 #143507 (this)
• ESQL: TSTEP #2 #144711
• ESQL: TSTEP #3 #144966
• ESQL: TSTEP #4 #144967

[github-actions]

🔍 Preview links for changed docs

• docs/reference/query-languages/esql/kibana/docs/functions/tstep.md

[github-actions]

ℹ️ Important: Docs version tagging

👋 Thanks for updating the docs! Just a friendly reminder that our docs are now cumulative. This means all 9.x versions are documented on the same page and published off of the main branch, instead of creating separate pages for each minor version.

We use applies_to tags to mark version-specific features and changes.

Expand for a quick overview

When to use applies_to tags:

✅ At the page level to indicate which products/deployments the content applies to (mandatory)
✅ When features change state (e.g. preview, ga) in a specific version
✅ When availability differs across deployments and environments

What NOT to do:

❌ Don't remove or replace information that applies to an older version
❌ Don't add new information that applies to a specific version without an applies_to tag
❌ Don't forget that applies_to tags can be used at the page, section, and inline level

🤔 Need help?

• Check out the cumulative docs guidelines
• Reach out in the #docs Slack channel

[sidosera]

@leontyevdv for thoughts on how to integrate this with your window function change.

[elasticsearchmachine]

Pinging @elastic/es-storage-engine (Team:StorageEngine)

[felixbarny]

This is a very large PR. Could you split it up into smaller chunks?

When this is in, we should be able to support PromQL instant queries where start=end, right?

TSTEP should also support specifying the number of target buckets similar to TBUCKET, see #144057 and #142747. These can be separate changes.

[sidosera]

@elasticmachine test this please

[sidosera]

@elasticmachine test this please

[sidosera]

@felixbarny

This is a large PR. Could you split it into smaller chunks?

Yeah, fair point. GitHub still makes stacked changes pretty awkward to manage, imo, so I usually avoid splitting things too much unless the diff starts getting hard to review. But this one is probably at that point, so I split it up a bit to make it easier to digest.

When this lands, we should be able to support PromQL instant queries where start = end, right?

Most likely, yes. But I didn't check that explicitly. We already use inclusive bounds, so start == end should match that exact timestamp I guess.

TSTEP should also support specifying the number of target buckets, similar to TBUCKET; see #144057 and #142747. These can be separate changes.

Agreed. We'll follow up on that separately.

[felixbarny]

Yeah, fair point. GitHub still makes stacked changes pretty awkward to manage, imo

I agree it's less than ideal. We should still avoid creating PRs with > 500 lines changed. Some recent learnings I had to make it a bit more bearable:

• If possible, avoid stacking by creating PRs that touch distinct set of files.
• When you do need to stack
  • Push the branches to origin/upstream, not your fork. That way you can actually stack your branches. For example pr-1 can target main and pr-2 can target pr-1. That way, when looking at pr-2, it doesn't show the commits of pr-1. When pr-1 gets merged, you can change the target from pr-2 to main.
  • Add a dependency graph of the stacked PRs as a simple nested markdown list. All PRs at the top-level are independent, stacked PRs add another nesting level.
  • Create the PRs around themes and give them a descriptive name (rather than #1, #2, #3)

[sidosera]

@elasticmachine test this please

[dnhatn]

One comment, but looks good. And sorry for the noise, Claude posted its review without asking.

[dnhatn]

Can we remove the extractTimestampBounds without nowSupplier

[sidosera]

Sure. Will follow-up in the next PRs.

[sidosera]

Test fails with multi-value errors in LIKE/RLIKE operators. This is unrelated to TSTEP.