The DB console transaction page treats two different transactions as the same fingerprint even though they have different counts of the same statement fingerprint.

Repro
Run the following:

  CREATE TABLE debug (id INT, name VARCHAR);
  
  BEGIN;
  INSERT INTO debug values(1, 'a');
  COMMIT;
  
  BEGIN;
  INSERT INTO debug values (1, 'a');
  INSERT INTO debug values(1, 'b');
  COMMIT;

Go to the DB console Transactions page and search for 'debug'. You expect to see two rows but there is 1 row. This single row also shows that the transaction fingerprint has an Execution Count of 3.

I suspect that because these transactions contain all the same statement fingerprint, we are treating it as a single transaction fingerprint; however, this doesn't explain why the Execution Count is 3. I would have expected two rows in the console page where each row has an Execution Count of 1.

Example:

T1: S1 (Read), S2 (Write)
T2: S2 (Write), S1 (Read)
T3: S2 (Write), S1 (Read), S2 (Write), S2 (Write)

Issue

All three transactions are treated as the same transaction fingerprint because they all have the same statement fingerprints (S1 and S2).

Improved behavior

We should treat them as separate transaction fingerprints because they can have differences in runtime statistics just based on ordering and number of their statements.

T3 should be different because the user can execute a transaction with a high number of statements of the same fingerprint and it can be aggregated with another transaction (like T1 or T2) with just a few statements of the same fingerprint.

T2 and T1 should be different fingerprints because the user can submit a statement dependent on the previous statement within the transaction. S1 can wait on S2 in T2 if it is reading from the same row S2 wrote. This dependency does not exist in T1.

For T3 scenario, we should consider updating the UX to avoid showing all statements. For instance, just show the counts S2(1x), S1(1x), S2(2x).

Epic: CRDB-9867