mirror of
https://github.com/GreptimeTeam/greptimedb.git
synced 2026-11-14 06:46:56 +00:00
feat(promql): answer a selector that names no metric by scanning each it matches A PromQL selector with no metric name used to be a planning error. It is now answered by enumerating the schema's logical metric tables, compiling one source per match under one union input, so the fused producer still reads what the compiler prepared: one compiler source per selector, not per metric. Each source names the metric it reads, in its own tag list. That is what makes this work at all: two metrics whose ordinary labels are equal are told apart by name alone, and nothing else in the response can carry that identity. Where the name survives is then a property of the operator rather than of discovery, so the same tag walk decides it for every query - the walk now drops the name where the runtime drops it, for a range function, a math or histogram kernel, a parameterized map, a timestamp selection and an arithmetic or `bool` binary operation, and keeps it for a filtering comparison. `sum by (__name__)` keeps it by grouping. The walk already had that same divergence without discovery: no metric-engine logical table carries `__name__` as a column, so a named selector's tags did not include it and the walk's answer was incomplete in the same way. Discovery only made the column real. The metric engine checks that two logical metrics agree on their time column's unit, not on its name, so each source's bound is built from the column that source actually carries, and a source without one is refused rather than read unbounded. Two upstream contracts assumed one table per selector and are widened rather than bypassed: the time-bound pushdown walks a union's sources, and a fused node may declare `__name__` when its inputs each name their own metric instead of binding one name itself. Declining still means the query goes to the existing planner; shapes this route cannot derive keep the plan they had. Signed-off-by: discord9 <discord9@163.com>