sql: add computed columns to crdb_internal persisted sql stats views

[ericharmeling]

Follows #99042, #99148.

This commit adds the following computed columns to both crdb_internal.statement_statistics_persisted and crdb_internal.transaction_statistics_persisted views:
-execution_count
-service_latency
-cpu_sql_nanos
-contention_time
-total_estimated_execution_time
-p99_latency

These computed columns are indexed in the system tables from which these views are created.

Epic: None

Release note: The crdb_internal.statement_statistics_persisted and crdb_internal.transaction_statistics_persisted views now include computed columns, to optimize the performance of frequently-queried expressions.

[cockroach-teamcity]

This change is 

[maryliag]

Reviewed 11 of 11 files at r1, 3 of 3 files at r2, all commit messages.
Reviewable status: complete! 1 of 0 LGTMs obtained (waiting on @ericharmeling)

[ericharmeling]

bors r+

[craig]

Build failed:

• Bazel Essential CI (Cockroach)

[ericharmeling]

bors retry

[craig]

Build succeeded:

• Bazel Essential CI (Cockroach)

[rytaft]

pkg/sql/opt/exec/execbuilder/testdata/sql_statistics_persisted line 4 at r3 (raw file):

statement ok
CREATE STATISTICS system_statement_stats FROM system.statement_statistics

Sorry for the late drive-by, but what was the goal with collecting statistics here? The table is empty, so this test is not going to be representative of what the plan would look like with a lot of rows. I would suggest either removing this call to CREATE STATISTICS (in which case the optimizer will default to assuming 1000 rows), or use ALTER TABLE ... INJECT STATISTICS and inject stats corresponding to what the table looks like with, say, 1 million rows.

Also, whenever you call CREATE STATISTICS in an execbuilder test like this, you'll need a retry on the next query that uses that table to avoid flakes (I already made that change in another PR, but FYI for the future). The retry is not needed for INJECT STATISTICS, however, because that causes the cache to be invalidated immediately. So if you remove this line or change it to use INJECT STATISTICS you can remove the retry directives I added.

[ericharmeling]

Reviewable status: complete! 0 of 0 LGTMs obtained (and 1 stale)

---

pkg/sql/opt/exec/execbuilder/testdata/sql_statistics_persisted line 4 at r3 (raw file):

what was the goal with collecting statistics here?

I want to make sure we are using the new secondary indexes on the underlying system._statistics tables for this specific query. Without statistics, the EXPLAIN plan output has scans of the primary index for the subqueries, rather than the secondary indexes on the system table.

I would suggest either removing this call to CREATE STATISTICS (in which case the optimizer will default to assuming 1000 rows), or use ALTER TABLE ... INJECT STATISTICS and inject stats corresponding to what the table looks like with, say, 1 million rows.

Also, whenever you call CREATE STATISTICS in an execbuilder test like this, you'll need a retry on the next query that uses that table to avoid flakes (I already made that change in another PR, but FYI for the future). The retry is not needed for INJECT STATISTICS, however, because that causes the cache to be invalidated immediately. So if you remove this line or change it to use INJECT STATISTICS you can remove the retry directives I added.

I'll open a new PR to use INJECT STATISTICS here instead of CREATE STATISTICS and remove the retry directives. Then I'll try to backport that (I just merged the backport of this PR 😬). 1 million rows is the maximum that these tables can hold, so that would work well.

Thank you!