`source=t | fields status | stats count(status)` never runs — it fails to
plan with "RexInputRef index 6 out of range 0..0". `dc(status)` fails the
same way. The trigger is a `fields` that narrows the row in front of an
ungrouped `count(<field>)` or `dc(<field>)`; `count()` with no argument,
every other aggregate, and anything with a `by` clause are unaffected.
count(field) counts non-null values, so an IS NOT NULL filter is added
under the aggregate — that is what lets OpenSearch answer the whole query
as a document count instead of an aggregation. The filter is stacked on
the projection, so its reference must be the column's index in the
projection's output, but the index used was the column's index in the
projection's input: after `fields status`, status is $0 above the
projection and $6 below it, and $6 is past the end of the row the filter
sees.
The fix takes the reference from refsPerCount, which already holds
output-side indices. Nothing is removed: the input-side mapping still
runs on the line above, where it does the job it was added for — proving
two names are one column, so `count(a), count(alias_of_a)` adds one
filter rather than two.
The explain golden file changes with it. Its query
(`eval name = lastname | stats count(name)`) widens the row, so the old
index was in range and happened to hold the same value — that query was
correct before and is correct now, and only the printed reference moves,
from the aliased source column to the column being counted.
Signed-off-by: Marc Handalian <handalm@amazon.com>
A query like
source=t | fields status | stats count(status)fails with "RexInputRef index 6 out of range 0..0".dc(status)fails the same way. The trigger is afieldsthat narrows the row in front of an ungroupedcount(<field>)ordc(<field>);count()with no argument, every other aggregate, and anything with abyclause are unaffected.count(field) counts non-null values, so an IS NOT NULL filter is added under the aggregate, that is what lets OpenSearch answer the whole query as a document count instead of an aggregation. The filter is stacked on the project node, so its reference must be the column's index in the project's output, but the index used was the column's index in the project's input: after
fields status, status is $0 above the projection and $6 below it, and $6 is past the end of the row the filter sees.The fix takes the reference from refsPerCount, which holds output-side indices.
I had to make a change to a test golden, the query (
eval name = lastname | stats count(name)) widens the row, so the old index was in range and happened to hold the same value. That query was correct before and is correct now, and only the printed reference moves, from the aliased source column to the column being counted.Description
[Describe what this change achieves]
Related Issues
Resolves #[Issue number to be closed when this PR is merged]
Check List
--signoffor-s.By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.