EsqlSession.fieldNames determines what fields from an index are required to compute a query, and is used to construct a field caps request before further analyzing the query.
For METRICS commands, it always determines that the @timestamp field will be required. Currently, UnresolvedRelation.references contains this logic (and it's being moved into EsqlSession.fieldNames in #111413).
However, the exact relationship to the METRICS command is not immediately clear from the code; one has to know that the only way for an UnresolvedRelation to have indexMode TIME_SERIES, it needs to come from parsing a METRICS command.
Maybe this logic shouldn't be placed inside UnresolvedRelation, but instead inside Aggregate - or maybe MERTRICS should use a special QueryPlan class that inherits from Aggregate, rather than being expressed in Aggregate.aggregateType.
EsqlSession.fieldNames determines what fields from an index are required to compute a query, and is used to construct a field caps request before further analyzing the query.
For
METRICScommands, it always determines that the@timestampfield will be required. Currently, UnresolvedRelation.references contains this logic (and it's being moved into EsqlSession.fieldNames in #111413).However, the exact relationship to the
METRICScommand is not immediately clear from the code; one has to know that the only way for anUnresolvedRelationto haveindexModeTIME_SERIES, it needs to come from parsing aMETRICScommand.Maybe this logic shouldn't be placed inside
UnresolvedRelation, but instead insideAggregate- or maybeMERTRICSshould use a specialQueryPlanclass that inherits fromAggregate, rather than being expressed inAggregate.aggregateType.