Skip to content

Add TimestampBoundsAware analysis mechanism#142750

Merged
felixbarny merged 17 commits intoelastic:mainfrom
felixbarny:timestamp-bounds-aware
Mar 11, 2026
Merged

Add TimestampBoundsAware analysis mechanism#142750
felixbarny merged 17 commits intoelastic:mainfrom
felixbarny:timestamp-bounds-aware

Conversation

@felixbarny
Copy link
Copy Markdown
Member

Introduce timestamp-bounds-aware analysis plumbing and use it to inject filter-derived bounds into PromqlCommand range queries during analysis.

Refactors PromQL timestamp-bounds inference from a one-off instanceof PromqlCommand check in EsqlSession.execute() into a generic, extensible analysis mechanism:

  • New TimestampBoundsAware<T> marker interface for nodes (expressions or plans) that need @timestamp bounds from the query DSL filter
  • ResolveTimestampBoundsAware analyzer rule to inject bounds during analysis
  • checkUnresolvedTimestampBounds verifier check to reject expressions still missing bounds after analysis
  • PromqlCommand refactored to implement the new interface
  • AnalyzerContext extended to carry TimestampBounds
  • EsqlSession.analyzedPlan() extracts bounds from the request filter and passes them to the context

The next step for this is to make TBUCKET TimestampBoundsAware once #142747 is merged. This will allow simpler usage of it in Kibana, for example: TBUCKET(100) rather than TBUCKET(100, ?_tstart, ?_tend).

Introduce timestamp-bounds-aware analysis plumbing and use it to inject
filter-derived bounds into PromqlCommand range queries during analysis.
@felixbarny felixbarny self-assigned this Feb 20, 2026
@felixbarny felixbarny added the :StorageEngine/ES|QL Timeseries / metrics / PromQL / logsdb capabilities in ES|QL label Feb 20, 2026
@elasticsearchmachine elasticsearchmachine added external-contributor Pull request authored by a developer outside the Elasticsearch team Team:StorageEngine v9.4.0 labels Feb 20, 2026
@elasticsearchmachine
Copy link
Copy Markdown
Collaborator

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

@kkrik-es
Copy link
Copy Markdown
Member

Before onboarding on this, let's get alignment on the syntax and the expected outcome. Mind putting together a single-pager and sharing with metrics program and esql? Such changes are far-reaching.

@felixbarny
Copy link
Copy Markdown
Member Author

felixbarny commented Feb 20, 2026

Makes sense. Note that this change in particular doesn't add any functional changes. It just adds a more generic mechanism how to get access to the TimestampBounds, replacing the explicit wiring for PromQL in EsqlSession.

Copy link
Copy Markdown
Member

@fang-xing-esql fang-xing-esql left a comment

Choose a reason for hiding this comment

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

Thank you @felixbarny, the approach of TimestampBoundsAware looks reasonable to me, if we can have some negative tests that will be very helpful to walk through how it works.

We have a couple of interfaces like PostAnalysisVerificationAware and PostAnalysisPlanVerificationAware, I wonder how does TimestampBoundsAware work with them? A lot of times the verification of a plan or a function is inside the plan or the function itself, I wonder if we want to follow that convention. @bpintea designed a lot of these interfaces, perhaps wait for @bogdan to take a look, in case I overlooked anything.

@felixbarny
Copy link
Copy Markdown
Member Author

felixbarny commented Mar 6, 2026

We have a couple of interfaces like PostAnalysisVerificationAware and PostAnalysisPlanVerificationAware, I wonder how does TimestampBoundsAware work with them? A lot of times the verification of a plan or a function is inside the plan or the function itself, I wonder if we want to follow that convention. @bpintea designed a lot of these interfaces, perhaps wait for @bogdan to take a look, in case I overlooked anything.

Good catch. My initial idea was that LogicalPlans would validate this via PostAnalysisVerificationAware#postAnalysisVerification but that we'd validate this for TimestampBoundsAware.OfExpression generically in the verifier. This was based on the wrong assumption that Expressions can't be PostAnalysisVerificationAware. Let me change it so that all implementations of TimestampBoundsAware are responsible for validating themselves.

@coderabbitai
Copy link
Copy Markdown
Contributor

coderabbitai bot commented Mar 6, 2026

Important

Review skipped

Auto reviews are limited based on label configuration.

🏷️ Required labels (at least one) (2)
  • Team:Delivery
  • Team:Search - Inference

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yml

Review profile: CHILL

Plan: Pro

Run ID: d545db5e-071a-4bd9-9be4-2be70575a0e8

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • ✅ Review completed - (🔄 Check again to review again)
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment

Comment @coderabbitai help to get the list of available commands and usage tips.

@felixbarny
Copy link
Copy Markdown
Member Author

@coderabbitai review

@coderabbitai
Copy link
Copy Markdown
Contributor

coderabbitai bot commented Mar 6, 2026

✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

Copy link
Copy Markdown
Member

@fang-xing-esql fang-xing-esql left a comment

Choose a reason for hiding this comment

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

LGTM, thank you @felixbarny !

Copy link
Copy Markdown
Contributor

@bpintea bpintea left a comment

Choose a reason for hiding this comment

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

Didn't do a deep review, but conceptually LGTM.

@felixbarny felixbarny enabled auto-merge (squash) March 11, 2026 14:50
@felixbarny felixbarny merged commit 99185b1 into elastic:main Mar 11, 2026
35 of 36 checks passed
jdconrad pushed a commit to jdconrad/elasticsearch that referenced this pull request Mar 11, 2026
Introduce timestamp-bounds-aware analysis plumbing and use it to inject
filter-derived bounds into PromqlCommand range queries during analysis.
jdconrad pushed a commit to jdconrad/elasticsearch that referenced this pull request Mar 11, 2026
Introduce timestamp-bounds-aware analysis plumbing and use it to inject
filter-derived bounds into PromqlCommand range queries during analysis.
jdconrad pushed a commit to jdconrad/elasticsearch that referenced this pull request Mar 11, 2026
Introduce timestamp-bounds-aware analysis plumbing and use it to inject
filter-derived bounds into PromqlCommand range queries during analysis.
jdconrad pushed a commit to jdconrad/elasticsearch that referenced this pull request Mar 11, 2026
Introduce timestamp-bounds-aware analysis plumbing and use it to inject
filter-derived bounds into PromqlCommand range queries during analysis.
jdconrad pushed a commit to jdconrad/elasticsearch that referenced this pull request Mar 11, 2026
Introduce timestamp-bounds-aware analysis plumbing and use it to inject
filter-derived bounds into PromqlCommand range queries during analysis.
michalborek pushed a commit to michalborek/elasticsearch that referenced this pull request Mar 23, 2026
Introduce timestamp-bounds-aware analysis plumbing and use it to inject
filter-derived bounds into PromqlCommand range queries during analysis.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

external-contributor Pull request authored by a developer outside the Elasticsearch team >non-issue :StorageEngine/ES|QL Timeseries / metrics / PromQL / logsdb capabilities in ES|QL Team:StorageEngine v9.4.0

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants