Translate start/end to filter on @timestamp

[felixbarny]

The start/end parameters are optional. If set, this creates a simple filter on the timestamp.

If start/end is not set, this doesn't create a filter and if @ start() and @ end() functions are used, it throws an error during parsing.

We don't attempt to infer start/end from other filters and we don't do anything special if there's another filter on @timestamp.

For instant queries where start=end=time, this essentially creates a filter that only includes data for a particular instant. We'll need to wire the lookback that will come after the initial window function support later on. Right now, instant queries will essentially always return an empty result. Maybe we just add a verifier rule to disallow instant queries.

[elasticsearchmachine]

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

[costin]

Suggest an improvement in creating the filter otherwise LGTM

[costin]

Since only one of start and end might be missing, handle each individually then assemble the filter using Predicates.combineAnd at the end:

List<Expression> timestampFilter = new ArrayList<>();

if (promqlCommand.start() ..) {
      timestampFilter.add(new GreaterThan,...)
}
if (promqlCommand.end() ..) {
      timestampFilter.add(new LessThan...)
}

if (timestampFilter.isEmpty() == false) {
        plan = new Filter(..., plan, Predicates.combineAnd(timestampFilter)
}

[felixbarny]

Since only one of start and end might be missing

I don't think that can happen. We're validating that either both or none are set:

elasticsearch/x-pack/plugin/esql/src/main/java/org/elasticsearch/xpack/esql/parser/LogicalPlanBuilder.java

Lines 1337 to 1344 in 53436ac

	if (start == null || end == null) {
	throw new ParsingException(
	source,
	"Parameters [{}] and [{}] must either both be specified or both be omitted for a range query",
	START,
	END
	);
	}