Tracking Issue: Improve PromQL compliance

[waynexia]

What type of enhancement is this?

User experience

What does the enhancement do?

Follows #596. The next stage after PromQL got initially supported is to improve its compatibility continuously.

Compliance History

PR	Compliance	Report	Notes
#1022	72 / 548 (13.14%)	2023-02-19	stale NaN is avoided
#1049	112 / 548 (20.44%)	2023-02-21	stale NaN is avoided
#1061, #1066, #1072	181 / 548 (33.03%)	2023-02-23	stale NaN is avoided
#1289, #1287, #1291, #1258, #1304, #1306	280 / 548 (51.09%)	2023-04-03	stale NaN is avoided
#1345	298 / 548 (54.38%)	2023-04-07
#1362, #1641, #1844, #1838	365 / 548 (66.61%)	2023-06-28
#2626, #2651, #2839, #2854, #2879	450 / 548 (82.12%)	2023-12-05

Tasks

• Unimplemented Parts
  • Paren Expr feat: Support unary, paren, bool keyword and nonexistent metric/label in PromQL #1049
  • Unary Expr feat: Support unary, paren, bool keyword and nonexistent metric/label in PromQL #1049
  • Subquery Expr
  • Literal Only Expr feat: impl literal only PromQL query #1641
  • time() feat: impl quantile_over_time function #1287
  • bool grammar feat: Support unary, paren, bool keyword and nonexistent metric/label in PromQL #1049
  • comparison filter feat: support filter expression in PromQL #1066
  • label_replace, label_join
  • on / ignoring join
  • offset incorrect result fix: lots of corner cases in PromQL #1345
  • aggr_over_time
    • others except stdvar_over_time() and stddev_over_time() feat: impl proc macro range_fn and some aggr_over_time functions  #1072
    • stddev_over_time() feat(stddev_over_time): add initial implementation #1289
    • stdvar_over_time() feat: implement stdvar_over_time function #1291
    • quantile_over_time() feat: impl quantile_over_time function #1287
  • range functions
    • idelta feat: add DictionaryVector DataType #1061
    • rate, increase, delta feat: implelemt rate, increase and delta in PromQL #1258
    • changes feat(changes): add initial implementation #1304
    • resets feat(resets): add initial implementation #1306
    • holt_winters feat(promql): add holt_winters initial implementation #1342
    • predict_linear feat: implement predict_linear function in promql #1362
  • functions
    • count, sort
    • topk, bottomk
    • quantile
    • timestamp
    • day_of_month, day_of_week, days_in_month, hour, minute, month, year feat: support time() and related functions in PromQL #2854
    • clamp_min, clamp_max, clamp
  • histogram
    • feat: implement HistogramFold plan for prometheus histogram type #2626
    • feat: implement histogram_quantile in PromQL #2651
• Incompatible Parts
  • Query non_exist_label / non_exist_metric will report an error rather than an empty result feat: Support unary, paren, bool keyword and nonexistent metric/label in PromQL #1049
  • stdvar and stddev's results are different feat: Support unary, paren, bool keyword and nonexistent metric/label in PromQL #1049
  • Special NaN is ignored feat: support bool operator with other computation #1844

Implementation challenges

No response

[aierui]

Can this part of PromQL be abstracted into a separate crate? Provide it to IOx for reuse.

[waynexia]

Can this part of PromQL be abstracted into a separate crate? Provide it to IOx for reuse.

It's already a separate crate under src/promql

[dekelpilli]

I can create a separate issue if you prefer, but there's currently a bug where queries that use {__name__="metric_name"} instead of the sugar alternative (metric_name{}) cause greptime to attempt to look up a value in a column named __name__ in addition to using it to infer the table name.

[waynexia]

Hi @dekelpilli, thanks for reporting it! I've filed #3213 to fix it.

This might be a regression after implementing the __field__ grammar extension. We didn't have a test to cover this behavior before 😖 (it's added now, thanks again ❤️)