[+] add stat_statements_jit metric

[0xgouda]

• Update stat_statements metric to query jit_generation_time.
• Add a new JIT % panel to 0. Health Check dashboard.
• Add a new Top n by JIT % to Global Health dashboard.
• Add a new JIT % column in Query Performance Analysis dashboard.

---

The JIT % represents the total amount of query execution time spent in JIT.

Closes: #1046

[coveralls]

Pull Request Test Coverage Report for Build 19931639127

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 73.615%

---

Totals
Change from base Build 19930713686:	0.0%
Covered Lines:	3694
Relevant Lines:	5018

---

💛 - Coveralls

[pashagolub]

We don't need another metric. We need updated stat_statements metric with a new column

[0xgouda]

We don't need another metric. We need updated stat_statements metric with a new column

That's what I did at first, but I noticed that stat_statements_calls metric exists and it directly aggregates the calls column instead of relying on the calls column in the stat_statements metric, so I did the same?

[pashagolub]

The reason for a separate stat_statements_calls is simple:

            stat_statements: 180
            stat_statements_calls: 60

We want to run it every minute because it's lightweight. But everything else goes into stat_statements.

[0xgouda]

We want to run it every minute because it's lightweight. But everything else goes into stat_statements.

Yep, exactly; stat_statements_jit is almost identical to stat_statements_calls, just fetching a different field, so we may add it to presets (forgot to do so, on it) with a smaller interval than stat_statements as well.

Also, if we just fetch another column in stat_statements, we will end up adding the union below to the query, which will complicate the query (increase the number of returned rows) and won't be very precise at the end.

UNION
    SELECT
        *
    FROM (
         SELECT
              *
          FROM
                q_data
          WHERE
                 jit_generation_time > 0
          ORDER BY
                jit_generation_time DESC
          LIMIT 100
     ) a
)

sounds okay?

[pashagolub]

No. jit goes to stat_statements

[pashagolub]

The thing is, if jit is not slow, we don't care

[pashagolub]

Good question is: should we rewrite stat_statements? These UNION clauses look really ugly

[pashagolub]

Another thing to think is plan related metrics. We need them as well

[0xgouda]

Another thing to think is plan related metrics. We need them as well

On my todo list.

[0xgouda]

No. jit goes to stat_statements

done, please review.

Also, if you think there are more useful panels for JIT than the ones added, please let me know.

[pashagolub]

I don't think we want to duplicate it here

[pashagolub]

why did you remove jit from no_query metric?

[0xgouda]

why did you remove jit from no_query metric?

Oh, Isn't that what you meant here :-) #1054 (comment)?