Skip to content

2.27.0.0-b355

2.27.0.0-b355: [#TBD] YSQL: Print transaction type in EXPLAIN (ANALYZE, DEBUG) output
@karthik-ramanathan-3006 karthik-ramanathan-3006 tagged this 21 Jul 14:58 
Summary:
This revision introducing printing of transaction type in EXPLAIN (ANALYZE) output as follows:
```
yugabyte=# EXPLAIN (ANALYZE, DIST, DEBUG) UPDATE simple SET v = v + 1 WHERE k = 1;
                                            QUERY PLAN
--------------------------------------------------------------------------------------------------
 Update on simple  (cost=0.00..4.12 rows=0 width=0) (actual time=7.573..7.574 rows=0 loops=1)
   ->  Result simple  (cost=0.00..4.12 rows=1 width=68) (actual time=0.004..0.004 rows=1 loops=1)
         Storage Table Write Requests: 1
           Metric rocksdb_number_db_seek: 1.000
           Metric rocksdb_number_db_next: 3.000
           Metric rocksdb_number_db_seek_found: 1.000
           Metric rocksdb_number_db_next_found: 2.000
           Metric rocksdb_iter_bytes_read: 97.000
           Metric picked_read_time_on_docdb: 1.000
           Metric write_lock_latency: sum: 27.000, count: 1.000
           Metric ql_write_latency: sum: 3284.000, count: 1.000
 Planning Time: 0.302 ms
 Execution Time: 7.703 ms
 Storage Read Requests: 0
 Storage Rows Scanned: 0
 Catalog Read Requests: 0
 Catalog Write Requests: 0
 Storage Write Requests: 1
 Storage Flush Requests: 0
   Metric rocksdb_number_db_seek: 1
   Metric rocksdb_number_db_next: 3
   Metric rocksdb_number_db_seek_found: 1
   Metric rocksdb_number_db_next_found: 2
   Metric rocksdb_iter_bytes_read: 97
   Metric picked_read_time_on_docdb: 1
   Metric write_lock_latency: sum: 27, count: 1
   Metric ql_write_latency: sum: 3284, count: 1
 Storage Execution Time: 0.000 ms
 Transaction: Fast Path                                                               <--- new field
 Peak Memory Usage: 8 kB
(30 rows)
```

**Behavior**
 - The transaction field may be one of the following: `{"Fast Path", <empty>}`
 - The transaction field is not printed for distributed transactions to reduce noise (as that is the default).
 - The transaction field is also not printed when the statement only involves reads or writes to temp tables.
 - The transaction field is printed ONLY when the query is **executed** with EXPLAIN (ANALYZE, DEBUG) ie. it is NOT printed with just EXPLAIN .
    - This is because there are known scenarios where a Single Shard is planned, but query execution ends up using a Distributed transaction. Such behavior would be confusing from an end user point of view.

This revision uses the following criteria to determine whether the current transaction uses the fast path:
 - The transaction has at least one write (today, fast path transactions can have exactly one write).
 - The isolation level of the transaction is not computed and evaluates to `NON_TRANSACTIONAL` (this implies that the transaction has no reads).
 - The transaction has no buffered writes at the end of the statement (statements in stored procedures may not compute their isolation level until writes are flushed, and writes may not be flushed at the statement boundary).

This is the first part of a series of changes that aim to eventually move the computation of single shard transactions to pggate (from the planner) (IDEA-2276).

Test Plan:
Run the following tests:
```
./yb_build.sh --java-test 'org.yb.pgsql.TestPgRegressPushdown'
```

Reviewers: pjain, smishra

Reviewed By: pjain

Subscribers: yql

Tags: #jenkins-ready

Differential Revision: https://phorge.dev.yugabyte.com/D44135
Assets 2
Loading