sql: add contended tables, indexes, and keys views

[matthewtodd]

These support developers in interpreting the existing contention information in cluster_contention_events.

Resolves: #61507

See also: #57114, #61625

Release note (sql change): Three new views were added to the crdb_internal schema to support developers investigating contention events, cluster_contended_{tables, indexes, keys}.

> SELECT * FROM crdb_internal.cluster_contended_tables
  database_name | schema_name | table_name | num_contention_events
----------------+-------------+------------+------------------------
  ycsb          | public      | usertable  |                    76
(1 row)

> SELECT * FROM crdb_internal.cluster_contended_indexes
  database_name | schema_name | table_name | index_name | num_contention_events
----------------+-------------+------------+------------+------------------------
  ycsb          | public      | usertable  | primary    |                    76
(1 row)

> SELECT * FROM crdb_internal.cluster_contended_keys
  database_name | schema_name | table_name | index_name |                  key                  | num_contention_events
----------------+-------------+------------+------------+---------------------------------------+------------------------
  ycsb          | public      | usertable  | primary    | /53/1/"user12161962213042174405"/1/1  |                     3
  ycsb          | public      | usertable  | primary    | /53/1/"user12161962213042174405"/2/1  |                     2
  ycsb          | public      | usertable  | primary    | /53/1/"user12161962213042174405"/3/1  |                     4
  ycsb          | public      | usertable  | primary    | /53/1/"user12161962213042174405"/4/1  |                     8
  ycsb          | public      | usertable  | primary    | /53/1/"user12161962213042174405"/5/1  |                     7
  ycsb          | public      | usertable  | primary    | /53/1/"user12161962213042174405"/6/1  |                     7
  ycsb          | public      | usertable  | primary    | /53/1/"user12161962213042174405"/7/1  |                     7
  ycsb          | public      | usertable  | primary    | /53/1/"user12161962213042174405"/8/1  |                     7
  ycsb          | public      | usertable  | primary    | /53/1/"user12161962213042174405"/9/1  |                     2
  ycsb          | public      | usertable  | primary    | /53/1/"user12161962213042174405"/10/1 |                     1
  ycsb          | public      | usertable  | primary    | /53/1/"user14856124470027295614"/1/1  |                     1
  ycsb          | public      | usertable  | primary    | /53/1/"user14856124470027295614"/10/1 |                     1
  ycsb          | public      | usertable  | primary    | /53/1/"user16390143479181108970"/1/1  |                     2
  ycsb          | public      | usertable  | primary    | /53/1/"user16390143479181108970"/2/1  |                     1
  ycsb          | public      | usertable  | primary    | /53/1/"user16390143479181108970"/4/1  |                     1
  ycsb          | public      | usertable  | primary    | /53/1/"user16390143479181108970"/5/1  |                     1
  ycsb          | public      | usertable  | primary    | /53/1/"user16390143479181108970"/6/1  |                     4
  ycsb          | public      | usertable  | primary    | /53/1/"user16390143479181108970"/7/1  |                     3
  ycsb          | public      | usertable  | primary    | /53/1/"user16390143479181108970"/9/1  |                     2
  ycsb          | public      | usertable  | primary    | /53/1/"user2171580671610491919"/1/1   |                     2
  ycsb          | public      | usertable  | primary    | /53/1/"user2171580671610491919"/3/1   |                     1
  ycsb          | public      | usertable  | primary    | /53/1/"user2171580671610491919"/4/1   |                     2
  ycsb          | public      | usertable  | primary    | /53/1/"user2171580671610491919"/7/1   |                     1
  ycsb          | public      | usertable  | primary    | /53/1/"user2171580671610491919"/9/1   |                     1
  ycsb          | public      | usertable  | primary    | /53/1/"user4838870532157485734"/4/1   |                     1
  ycsb          | public      | usertable  | primary    | /53/1/"user4865742928595613128"/7/1   |                     1
  ycsb          | public      | usertable  | primary    | /53/1/"user6399761937749426484"/3/1   |                     1
  ycsb          | public      | usertable  | primary    | /53/1/"user6399761937749426484"/6/1   |                     1
  ycsb          | public      | usertable  | primary    | /53/1/"user6399761937749426484"/8/1   |                     1
(29 rows)

[cockroach-teamcity]

This change is 

[jordanlewis]

Excellent work!

I'm, at a high level, wondering about 2 things (both product level):

1. Internal table architecture-wise, do we prefer our join keys to be by-name (in which case any joins must be accomplished by including all 3 of the names in a join) or by-id (in which case joins can be accomplished by just the table id, which are cluster-wide unique?)
2. Do we need to redact the contention keys? The answer to this question might depend on the level of access that we provide to this table. It seems like a data leak waiting to happen unless we also test the querying user's SELECT capability on the tables.

Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @matthewtodd)

---

pkg/sql/crdb_internal.go, line 1753 at r1 (raw file):

    database_name, schema_name, name, sum(num_contention_events)
  FROM
    [

Interesting use of the cockroachdb-specific [] syntax! I'm curious, how did you come across this? In general we prefer the SQL-standard () subquery syntax, which is going to be better supported optimization-wise, unless you found a reason not to use it here?

[maryliag]

2. I agree we should have redaction depending on the user's level of access to the table. Also, should we have some explanation or more details about what the value means? I don't think the user will necessarily knows what each value of the key means and even if you look for documentation I could only find https://www.cockroachlabs.com/docs/stable/functions-and-operators.html that simply states "This function is used only by CockroachDB’s developers for testing purposes."

Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @matthewtodd)

[matthewtodd]

Thank you both for the review!

For 1., I could use a little more context. I've asked in our #sql-observability-team to see more of what you mean, @jordanlewis.

For 2., AFAICT this change doesn't expose anything that isn't already available in crdb_internal.cluster_contention_events, which is already gated on a VIEWACTIVITY permission. And I assume a view doesn't work if the user can't select from its underlying tables, yes?

Alternatively, I've gone looking for column-specific permissions but not yet found anything. If those exist, could you point me in the right direction?

Prettifying keys was per @kevin-v-ngo's request, acknowledging that it's not yet an ideal answer. LMK if you think we should just revert to binary keys here for now, and I can do that easily.

Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @jordanlewis)

---

pkg/sql/crdb_internal.go, line 1753 at r1 (raw file):

Previously, jordanlewis (Jordan Lewis) wrote…

Interesting use of the cockroachdb-specific [] syntax! I'm curious, how did you come across this? In general we prefer the SQL-standard () subquery syntax, which is going to be better supported optimization-wise, unless you found a reason not to use it here?

Oops! Not sure where I saw this, will fix. Good catch!

[matthewtodd]

I think we're all set to merge this now! I've fixed my unintentional usage of cockroach-specific syntax, @kevin-v-ngo is following up on the key redaction issue, and @jordanlewis mentioned in our 1:1 this morning that his comments about the shape of these tables/views were more intended to raise our team's overall awareness (leading to Kevin's draft doc, awesome, Kevin!) than to block landing these changes as they are. Could I get an LGTM?

Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @jordanlewis)

---

pkg/sql/crdb_internal.go, line 1753 at r1 (raw file):

Previously, matthewtodd (Matthew Todd) wrote…

Oops! Not sure where I saw this, will fix. Good catch!

Done.

[maryliag]

Great work on this!

Reviewable status: complete! 1 of 0 LGTMs obtained (waiting on @jordanlewis)

[matthewtodd]

bors r+

[craig]

Build succeeded:

• GitHub CI (Cockroach)