Check for early termination in Driver

[dnhatn]

This change introduces support for periodically checking for early termination. This enables early exits in the following scenarios:

1. The query has accumulated sufficient data (e.g., reaching the LIMIT).
2. The query is stopped (either by users or due to failures).

Other changes will be addressed in follow-up PRs.

[elasticsearchmachine]

Pinging @elastic/es-analytical-engine (Team:Analytics)

[nik9000]

I wonder if we'd be better off having the Operator subclasses yield control - if they return null then the driver loop will check for them. But they have to store their intermediate state and that's annoying. This solution is more general though it's more "different" than the rest of the driver stuff works. Where are we looking at putting these?

[smalyshev]

Tested the newest version (b9deea7) locally and it seems to do the interruption mid-page properly.

[elasticsearchmachine]

Hi @dnhatn, I've created a changelog YAML for you.

[dnhatn]

Here's just one example - we might not need this for all evaluators, only for the expensive ones whose inputs or outputs are BytesRef.

[nik9000]

I think we almost certainly don't want it for most evaluators, but I can really see the use for bailing early for slow stuff - and, I think, all of those take or produce ByesRef. Automata match, geo stuff. Otherwise I think we're frequently dealing with more overhead than the operation. And we're quite likely to break autovectorization.

I wonder if instead of a "cost" this should be a, maybe simpler, "check for termination every n rows" style. p % <constant> == 0 is going to be pretty fast, especially if the constant is, like, 1 or 2 or 4 or 8. Hell, that feels like something loop unrolling might handle, though I don't think we're really worried about loop unrolling for these cases.

One thing that's really interesting - some of these automata matches are probably quite fast and not worth the checking. But we don't differentiate. And that's fine for now.

[nik9000]

I feel like we're really

[nik9000]

I think we almost certainly don't want it for most evaluators, but I can really see the use for bailing early for slow stuff - and, I think, all of those take or produce ByesRef. Automata match, geo stuff. Otherwise I think we're frequently dealing with more overhead than the operation. And we're quite likely to break autovectorization.

I wonder if instead of a "cost" this should be a, maybe simpler, "check for termination every n rows" style. p % <constant> == 0 is going to be pretty fast, especially if the constant is, like, 1 or 2 or 4 or 8. Hell, that feels like something loop unrolling might handle, though I don't think we're really worried about loop unrolling for these cases.

One thing that's really interesting - some of these automata matches are probably quite fast and not worth the checking. But we don't differentiate. And that's fine for now.

[dnhatn]

@nik9000 Thanks for the feedback. I have a previous implementation that unrolls loops to maintain auto-vectorization (for example:

elasticsearch/x-pack/plugin/esql/src/main/generated/org/elasticsearch/xpack/esql/expression/function/scalar/date/DateTruncDatetimeEvaluator.java

Lines 83 to 92 in 71d42f1

	// generate a tight loop to allow vectorization
	int maxBatchSize = Math.max(DriverContext.CHECK_FOR_EARLY_TERMINATION_COST_THRESHOLD / 1, 1);
	for (int start = 0; start < positionCount; ) {
	int end = start + Math.min(positionCount - start, maxBatchSize);
	driverContext.checkForEarlyTermination();
	for (int p = start; p < end; p++) {
	result.appendLong(p, DateTrunc.processDatetime(fieldValVector.getLong(p), this.rounding));
	}
	start = end;
	}

). I removed it to keep this PR small and will spin off the evaluator work to unblock Stas's progress.

[nik9000]

I removed it to keep this PR small and will spin off the evaluator work to unblock Stas's progress.

👍

[dnhatn]

@smalyshev @nik9000 Thanks for reviews + feedback!

[dnhatn]

Backported to 8.18 in #120238