GreptimeTeam / greptimedb

An open-source, cloud-native, distributed time-series database with PromQL/SQL/Python supported. Available on GreptimeCloud.
https://greptime.com/
Apache License 2.0
3.97k stars 287 forks source link

Tracking Issue: Improve PromQL compliance #1042

Open waynexia opened 1 year ago

waynexia commented 1 year ago

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

Implementation challenges

No response

aierui commented 1 year ago

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

waynexia commented 1 year ago

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 commented 5 months ago

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 commented 5 months ago

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