vthriller
vthriller
Multiple reasons, actually, some of which I can no longer remember. One, for instance, was the need to work around inefficiencies in older Prometheus query processor: queries like `foo{a..., b...,...
@JohnnyQQQQ sorry for late response. I don't really know. I'm still interested in having up-to-date promql parser, but recent versions of nom are pretty finicky and hit recursion limit much...
> But my guess is that as queries become more complicated, the exact relationship between variables in PRQL & SQL become more difficult to track, and so using names across...
In short, skipping all new functions that are of no interest to us: - aggr. op limits: `sum(x) by (y) limit 10` - why not expand that to vectors as...
> funny that I sometimes wish I could stick ranges in arbitrary places Turns out [subqueries are now a thing](https://prometheus.io/blog/2019/01/28/subquery-support/)
Comments are also supported by Prometheus 2.14 (#3).
It seems VM also accepts period as valid vector name character (see also #1): - https://github.com/VictoriaMetrics/metricsql/blob/6c5bef8a3d2cf50b14061a0806035955c01f3074/lexer.go#L478-L483 - https://github.com/VictoriaMetrics/metricsql/blob/6c5bef8a3d2cf50b14061a0806035955c01f3074/lexer_test.go#L22 - https://github.com/VictoriaMetrics/metricsql/blob/6c5bef8a3d2cf50b14061a0806035955c01f3074/lexer_test.go#L52 Prometheus though still rejects `foo.bar`: https://github.com/prometheus/prometheus/blob/1f69c38ba4c104520732d416de2894052806cea7/promql/parser/lex.go#L756
> #271 Well, that might've explained the last observation, but my TurboVNC is already v3.1.1, which, as GitHub indicates, already contains [TurboVNC/turbovnc@b4fd6ae](https://github.com/TurboVNC/turbovnc/commit/b4fd6ae2a15f08c6052918d29511dffe37e4dae3).