Scalable Database Server, HiRDB Version 8 UAP Development Guide

[Contents][Index][Back][Next]

4.5.1 SQL optimizing modes

Organization of this subsection
(1) Features of the SQL optimizing modes
(2) SQL statements that forcibly apply optimizing mode 2 based on cost
(3) Valid scope of the SQL optimization option and SQL extension optimizing option
(4) Checking the SQL optimizing mode selected by the optimization process
(5) Notes

(1) Features of the SQL optimizing modes

Table 4-3 describes the features of the SQL optimizing modes.

Table 4-3 Features of the SQL optimizing modes

SQL optimizing mode Explanation Advantages Disadvantages Selection method
Optimizing mode 1 based on cost This is the optimization processing method based on cost for HiRDB versions before Version 06-00. This mode can also be used in HiRDB Version 06-00 and later versions. Even if HiRDB is upgraded from a version earlier than Version 06-00, searches can be performed with the same access paths used in the earlier version.
Access paths are sometimes changed for high-speed retrieval.
The optimal access path cannot always be selected because there are only a few access path candidates. (Access paths are not selected by setting facilities such as hash join as candidates.) Do not specify the SQL extension optimizing option, or clear the specification for application of optimizing mode 2 based on cost in the SQL extension optimizing option.
Some SQL statements always use optimizing mode 2 based on cost. For details, see (2) as follows.
Optimizing mode 2 based on cost This is the optimization processing method based on cost that is used in HiRDB Version 06-00 and later. This mode is designed for fast retrieval. High-speed retrieval is possible because this mode selects access paths from candidates that combine hashing to join search and subquery processing. Optimization processing takes time because this mode performs complex optimization processing. Specify application of optimizing mode 2 based on cost in the SQL extension optimizing option.

(2) SQL statements that forcibly apply optimizing mode 2 based on cost

Even if optimizing mode 1 based on cost is being used, optimizing mode 2 based on cost is sometimes forcibly applied. The SQL statements that forcibly apply optimizing mode 2 based on cost are as follows:

The application condition and an example of each SQL sentence are shown as follows.

(a) Subquery in the SET clause of the UPDATE statement
(b) Outer join + (inner) join
(c) COUNT(*) in a set operation result
(d) Value expression of the DISTINCT set expression
(e) Specification of the query name of a viewed table or WITH clause to an outer join
(f) Addition update and partial extraction facility for BLOB and BINARY data
(g) HiRDB External Data Access facility
(h) SQL optimization specification
(i) Sorting with a value expression with a defined length exceeding 255 bytes
(j) Retrieve first n records
(k) Retrieval using the BINARY type
(l) Retrieval of a viewed table or WITH clause containing an internally derived table that becomes a nesting structure with at least two levels
(m) Matrix partitioning
(n) Subquery for a joined table
(o) Application of the MIN or MAX set function to a repetition column
(p) Row value constructor
(q) Subquery in the CASE expression
(r) POSITION scalar function in which value expression 2 is the BLOB type
(s) Referential constraint
(t) Check constraint
(u) Limit release to allow data with a defined length of 256 bytes or more
(v) Specification of a table targeted for data update, deletion, or addition in a subquery
(w) Unnesting facility for repetition column in the FROM clause
(x) LIMIT clause
(y) Search in which an internally derived table has two or more nesting layers
(z) Expansion of the specification location in the query expression body
(aa) Window functions
(ab) SIMILAR predicate

(3) Valid scope of the SQL optimization option and SQL extension optimizing option

Table 4-4 shows the SQL optimizing modes in which the SQL optimization option and SQL extension optimizing option are valid.

Table 4-4 SQL optimizing modes in which the SQL optimization option and SQL extension optimizing option are valid

SQL optimizing mode SQL optimization option SQL extension optimizing option
Optimizing mode 1 based on cost V [Figure]
Optimizing mode 2 based on cost V V

V: The option is valid in this mode.

[Figure]: The option is invalid in this mode.

(4) Checking the SQL optimizing mode selected by the optimization process

To check the SQL optimizing mode that was selected by the optimization process for each SQL statement, use the access path display utility. For details about the access path display utility, see the HiRDB Version 8 Command Reference manual.

(5) Notes

  1. When the SQL optimizing mode is changed, the search performance of an SQL statement may drop because the access path is changed. If the environment being used for actual operation does not allow adequate evaluation of performance, Hitachi recommends that you do not change the SQL optimizing mode.
  2. If you are installing HiRDB for the first time, Hitachi recommends that you use optimizing mode 2 based on cost. If you are using another SQL extension optimizing option, use it by adding it to optimizing mode 2 based on cost. By using optimizing mode 2 based on cost, you can select access paths capable of retrieving data faster because the optimization process can select many types of access paths.
    Normally, optimizing mode 2 based on cost is applied because it is the default value for the pd_additional_optimize_level operand in the HiRDB system definition. Optimizing mode 2 based on cost is also applied when you use the simple setup tool, the system generator, SPSetup.bat, or an environment setup support tool such as HiRDEF to set up your HiRDB environment.
  3. If you upgrade HiRDB from a version earlier than 06-00, Hitachi recommends that you continue to use optimizing mode 1 based on cost because you are using HiRDB in the same conditions as before the version upgrade. However, some SQL statements may always use optimizing mode 2 based on cost.
  4. Normally, the narrowing condition is considered in the optimization process. However, if a hash join, subquery hash execution is applied to the SQL extension optimizing option and there is no narrowing condition, or if the narrowing condition does not produce much narrowing of the number of rows, a hash join that sets a table with more rows as an inner table may be applied, or a table with more rows may be transferred. In such cases, execute the optimizing information collection utility by using one of the following methods, as necessary. For details about the necessity of executing the optimizing information collection utility, see the manual HiRDB Version 8 Command Reference and verify the performance.
    • With data stored in the table, set the optimizing information collection level to lvl1 (specify lvl1 in the -c option) and execute the optimizing information collection utility. When lvl1 is specified, the optimizing information collection utility can be executed in a relatively short time because the utility fetches only information on the number of rows in the table. To fetch the number of rows for all tables in the schema, specify ALL in the -t option.
    • If data cannot be stored in the table or if a test environment is being used, specify the number of rows (NROWS) found in the table used in the actual environment, specify the -s option for each table, and then execute optimization. The following is an example of the specification in the optimization parameter file when the number of rows in the table is set to 1,000:
      # Table optimization information
      NROWS 1000 # Total number of rows in table
  5. If you are using optimizing mode 1 based on cost, normally you do not need to execute the optimizing information collection utility. But if you do execute the utility, set the optimizing information collection level to lvl1.