Tsurugi 1.2.0 - Release Notes (en)

[akirakw]

1.2.0 Release Notes

Overview

In this version, improvements to index join processing (Index Join) have accelerated join processing under specific conditions.
Additionally, as an experimental feature, a function to speed up query execution by reading table data in parallel when using RTX has been introduced.

Furthermore, this version includes several important bug fixes and minor improvements.
All users of the previous version are strongly recommended to upgrade to this version.

New Features and Improvements

• SQL

  • Improvements to index join processing (Index Join)
    • In Index Join, additional support has been added for join operations (search and join processing using index key prefixes) that were partially supported since version 1.0.0. This allows queries that were previously processed with Shuffle Join due to the inability to utilize indexes to be processed with Index Join, resulting in faster join processing.
    • When this optimization is applied, the join processing in the execution plan displayed by executing the EXPLAIN statement in tgsql command will be shown as join (join_scan).
    • Depending on the join conditions, Shuffle Join may still be used.

• Transaction

  • (Experimental Feature) Parallel reading of table data when using RTX
    • In transactions specified with RTX (Read Only Transaction), query execution is accelerated by dividing and executing scan processing in parallel on the SQL execution engine, mainly speeding up the execution of SELECT statements that retrieve all rows or involve range searches.
  • In version 1.2.0, this feature is provided as an experimental feature. Therefore, there are many functional and performance limitations. Please note the following points when using this feature:
    • In the default settings of this version, this feature is disabled. To enable it, follow these steps:
      • Add the setting dev_rtx_parallel_scan=true to the sql section of the configuration file tsurugi.ini.
        • In this version, explicit settings are required to enable this feature as it is experimental, but it is planned to be enabled by default in future versions, making this setting unnecessary.
      • Optionally, specify the setting scan_default_parallel=(num of parallel) in the sql section of the configuration file tsurugi.ini.
        • This value represents the maximum number of parallel executions for scan processing by the SQL execution engine. The default value is 4.
        • In this version, due to insufficient optimization of parallel processing control, the upper limit of sql.scan_default_parallel that can be expected to improve performance is approximately 4 to 8. Additionally, depending on the environment, table content, and query content, the effects of parallel execution may not be realized.
    • In this version, the scan division processing part is an experimental implementation. Specifically, it extracts the byte sequence representing the maximum and minimum keys included in the scan range from the value of the search key (or the primary key value if the search key is not specified) and divides the byte sequence of that range at equal intervals. Therefore, effective scan division requires the following conditions to be met:
      • For numeric types, if the key values are uniformly distributed within the scan range, appropriate granularity division can be achieved.
      • For string types, if the leading part of the strings within the scan range is uniformly distributed, appropriate granularity division can be achieved.
      • If the key values contain nulls, the distribution will not be uniform, and appropriate granularity division will not be achieved.
      • If the key consists of multiple columns, the range division will prioritize the columns closer to the beginning. Therefore, even if the second and subsequent columns are uniformly distributed, appropriate division may not be achieved if the first column is not uniformly distributed.

Bug Fixes

• Transaction

  • In rare cases, when RTX and OCC conflict, SQL-02000: Unexpected error occurred. status:err_invalid_state may occur, causing the RTX transaction to fail.
  • If the tsurugidb process terminates abnormally due to a SIGKILL signal, there is a possibility that the transaction log may become inconsistent.
  • Unnecessary files may remain after executing the transaction log compression process.
  • If the transaction log compression process is executed while a session exists, the start of the compression process may be excessively delayed.

• Endpoint

  • In IPC sessions, the IPC endpoint may occasionally stop responding.

Known Issues

For known issues in this version and supplementary information on issues fixed in this version, refer to the following link:

• Tsurugi 1.2.0 - Known Issues(en)

Others

For a list of changes in this version, refer to the following Changelog:

• Tsurugi 1.2.0 - Changelog

For upgrade instructions from previous versions, refer to the following document:

• Tsurugi Upgrade Guide

---

This discussion was created from the release 1.2.0.