Add TimestampBoundsAware analysis mechanism#142750
Conversation
Introduce timestamp-bounds-aware analysis plumbing and use it to inject filter-derived bounds into PromqlCommand range queries during analysis.
|
Pinging @elastic/es-storage-engine (Team:StorageEngine) |
|
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. |
|
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 |
x-pack/plugin/esql/src/main/java/org/elasticsearch/xpack/esql/analysis/Analyzer.java
Outdated
Show resolved
Hide resolved
...sql/src/main/java/org/elasticsearch/xpack/esql/expression/function/TimestampBoundsAware.java
Show resolved
Hide resolved
x-pack/plugin/esql/src/main/java/org/elasticsearch/xpack/esql/session/EsqlSession.java
Show resolved
Hide resolved
fang-xing-esql
left a comment
There was a problem hiding this comment.
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.
x-pack/plugin/esql/src/main/java/org/elasticsearch/xpack/esql/analysis/Verifier.java
Outdated
Show resolved
Hide resolved
Good catch. My initial idea was that |
|
Important Review skippedAuto reviews are limited based on label configuration. 🏷️ Required labels (at least one) (2)
Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Path: .coderabbit.yml Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
fang-xing-esql
left a comment
There was a problem hiding this comment.
LGTM, thank you @felixbarny !
bpintea
left a comment
There was a problem hiding this comment.
Didn't do a deep review, but conceptually LGTM.
Introduce timestamp-bounds-aware analysis plumbing and use it to inject filter-derived bounds into PromqlCommand range queries during analysis.
Introduce timestamp-bounds-aware analysis plumbing and use it to inject filter-derived bounds into PromqlCommand range queries during analysis.
Introduce timestamp-bounds-aware analysis plumbing and use it to inject filter-derived bounds into PromqlCommand range queries during analysis.
Introduce timestamp-bounds-aware analysis plumbing and use it to inject filter-derived bounds into PromqlCommand range queries during analysis.
Introduce timestamp-bounds-aware analysis plumbing and use it to inject filter-derived bounds into PromqlCommand range queries during analysis.
Introduce timestamp-bounds-aware analysis plumbing and use it to inject filter-derived bounds into PromqlCommand range queries during analysis.
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 PromqlCommandcheck inEsqlSession.execute()into a generic, extensible analysis mechanism:TimestampBoundsAware<T>marker interface for nodes (expressions or plans) that need@timestampbounds from the query DSL filterResolveTimestampBoundsAwareanalyzer rule to inject bounds during analysischeckUnresolvedTimestampBoundsverifier check to reject expressions still missing bounds after analysisPromqlCommandrefactored to implement the new interfaceAnalyzerContextextended to carryTimestampBoundsEsqlSession.analyzedPlan()extracts bounds from the request filter and passes them to the contextThe next step for this is to make
TBUCKETTimestampBoundsAwareonce #142747 is merged. This will allow simpler usage of it in Kibana, for example:TBUCKET(100)rather thanTBUCKET(100, ?_tstart, ?_tend).