Tracking Issue: Improve PromQL compliance

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
  • [x] Paren Expr #1049
  • [x] Unary Expr #1049
  • [ ] Subquery Expr
  • [x] Literal Only Expr #1641
  • [x] time() #1287
  • [x] bool grammar #1049
  • [x] comparison filter #1066
  • [x] label_replace, label_join https://github.com/GreptimeTeam/greptimedb/pull/5153
  • [ ] on / ignoring join
  • [x] offset incorrect result #1345
  • [x] aggr_over_time
    • [x] others except stdvar_over_time() and stddev_over_time() #1072
    • [x] stddev_over_time() #1289
    • [x] stdvar_over_time() #1291
    • [x] quantile_over_time() #1287
  • [x] range functions
    • [x] idelta #1061
    • [x] rate, increase, delta #1258
    • [x] changes #1304
    • [x] resets #1306
    • [x] holt_winters #1342
    • [x] predict_linear #1362
  • [ ] functions
    • [ ] count, sort
    • [ ] topk, bottomk
    • [ ] quantile
    • [ ] timestamp
    • [x] day_of_month, day_of_week, days_in_month, hour, minute, month, year #2854
    • [x] clamp_min, clamp_max, clamphttps://github.com/GreptimeTeam/greptimedb/pull/3465
  • [x] histogram
    • [x] #2626
    • [x] #2651
• Incompatible Parts
  • [x] Query non_exist_label / non_exist_metric will report an error rather than an empty result #1049
  • [x] stdvar and stddev's results are different #1049
  • [x] Special NaN is ignored #1844

Implementation challenges

No response

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

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

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.

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 :heart:)

We can close this issue right now.