stmtsummary: implement tidb_statements_stats, a cumulative version of statements_summary

[henrybw]

What problem does this PR solve?

Issue Number: ref #57147

Problem Summary: The statement summary tables are the current mechanism we have for collecting cumulative metrics about the execution and performance of SQL queries. However, these metrics aren't truly cumulative: they are refreshed at a regular interval, meaning the cumulative metrics collected for queries are reset, and their previous values are made accessible via a separate history table. For the workload repository, we want to be able to snapshot cumulative metrics aggregated over the lifetime of a TiDB instance, which the statement summary tables do not easily provide.

What is changed and how it works?

• The statistics captured by the statement summaries for each interval have been factored out into a new struct, stmtSummaryStats, that each statement summary interval (stmtSummaryByDigestElement) now uses instead. The struct is embedded so existing field accesses continue to work as-is.
• In the statement summary struct itself (stmtSummaryByDigest), add a new "cumulative" set of statistics (i.e. another stmtSummaryStats struct).
• Create a new memory table, information_schema.tidb_statements_stats, that uses the same stmtSummaryRetriever as the statement summary tables.
• Modify the column factories for the statement summary rows reader to accept an additional stmtSummaryStats parameter. For the existing statement summary tables, this parameter is the stmtSummaryStats struct embedded in the stmtSummaryByDigestElement (i.e. the same values as before). For the new cumulative statement stats table, this parameter is the cumulative stmtSummaryStats struct in the stmtSummaryByDigest. The column factories then read from this stmtSummaryStats parameter, rather than the stmtSummaryByDigestElement struct directly, thus making them polymorphic and able to work for both the cumulative and statements summary tables.
• Add a cluster-wide version of the statement stats table: cluster_tidb_statements_stats.

(The diff for this PR is pretty large, so I'd recommend reading each individual commit one at a time, since they build on each other incrementally.)

Check List

Tests

• Unit test
• Integration test
• Manual test (add detailed scripts or steps below)
• No code

- Started tidb-server.
- Ran one query, e.g. `select 1;`.
- Verified that a row appeared for this query.
- Re-ran the query several more times.
- Verified that the cumulative stats in that row updated accordingly.
- Verified that the corresponding row in cluster_tidb_statements_stats updated accordingly.

Side effects

• Performance regression: Consumes more CPU
• Performance regression: Consumes more Memory
• Breaking backward compatibility

Documentation

• Affects user behaviors
• Contains syntax changes
• Contains variable changes
• Contains experimental features
• Changes MySQL compatibility

Release note

Please refer to Release Notes Language Style Guide to write a quality release note.

Add a new system table `INFORMATION_SCHEMA.TIDB_STATEMENTS_STATS` to provide cumulative metrics about the execution and performance of SQL queries on TiDB nodes.

[tiprow]

Hi @henrybw. Thanks for your PR.

PRs from untrusted users cannot be marked as trusted with /ok-to-test in this repo meaning untrusted PR authors can never trigger tests themselves. Collaborators can still trigger tests on the PR using /test all.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[codecov]

Codecov Report

Attention: Patch coverage is 77.63158% with 119 lines in your changes missing coverage. Please review.

Project coverage is 75.3833%. Comparing base (9812d85) to head (8900c16).
Report is 17 commits behind head on master.

Additional details and impacted files

@@               Coverage Diff                @@
##             master     #57155        +/-   ##
================================================
+ Coverage   73.1839%   75.3833%   +2.1994%     
================================================
  Files          1671       1719        +48     
  Lines        460731     474058     +13327     
================================================
+ Hits         337181     357361     +20180     
+ Misses       102827      94612      -8215     
- Partials      20723      22085      +1362     

Flag	Coverage Δ
integration	49.2403% <69.3609%> (?)
unit	72.7938% <77.6315%> (+0.4886%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Components	Coverage Δ
dumpling	52.6910% <ø> (ø)
parser	∅ <ø> (∅)
br	61.6560% <ø> (+15.6516%)	⬆️

[xhebox]

/retest

[tiprow]

@xhebox: Cannot trigger testing until a trusted user reviews the PR and leaves an /ok-to-test message.

In response to this:

/retest

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[xhebox]

/hold

[ti-chi-bot]

[LGTM Timeline notifier]

Timeline:

• 2024-11-06 11:03:00.553226698 +0000 UTC m=+1038893.392382239: ☑️ agreed by djshow832.
• 2024-11-15 04:52:59.029883883 +0000 UTC m=+591141.220752880: ☑️ agreed by xhebox.

[D3Hunter]

/approve

infoschema part lgtm

[Benjamin2037]

Can we add some input parameters to only needed stats back？like only return records after some ts

[henrybw]

Hmm, that is a good idea, but I'm not sure if it makes sense in this context. For in-memory tables like this, I think the kind of filtering you're referring to would be done at a higher level, by the executor.

Perhaps we could implement a "pushdown" mechanism (like predicate pushdown to TiKV) for in-memory tables like this. While that could be a useful feature, I think building something like that would be a pretty large project, and is thus out of scope for this PR.

[bb7133]

/rebuild

[xhebox]

/retest

[tiprow]

@xhebox: Cannot trigger testing until a trusted user reviews the PR and leaves an /ok-to-test message.

In response to this:

/retest

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[Rustin170506]

Thanks!

[ti-chi-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: D3Hunter, djshow832, Rustin170506, xhebox

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [D3Hunter,Rustin170506,djshow832,xhebox]
• pkg/infoschema/OWNERS [D3Hunter]
• pkg/planner/OWNERS [Rustin170506]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[xhebox]

/unhold

[hawkingrei]

@henrybw This PR introduces a data race. #58403