SQL/MX Programming Manual for Java
SQL/MX Programming Considerations
HP NonStop SQL/MX Programming Manual for Java—523726-003
4-29
Automatic Recompilation
•
Both tables must have the same partitioning scheme (hash or range partitioned),
the same number of partitions, and the same partitioning keys if the plan does not
use OLT optimization.
•
Both tables must not have any check constraints or referential integrity constraints.
•
The query must not use compound statements.
•
ESP parallelism must not have been used.
•
The query must not include any views.
•
A CALL statement must not refer to a stored procedure in Java (SPJ) that has
been dropped and re-created in SQL/MX.
If a statement fails the similarity check, the SQL/MX executor, by default, invokes the
SQL/MX compiler to automatically recompile the SQL plan. For more information, see
Automatic Recompilation on page 4-29.
Automatic Recompilation
Automatic recompilation is the run-time recompilation, invoked by the SQL/MX
executor, of a DML statement in a module. During automatic recompilation, the SQL
plan changes but is not written to the module. Instead, it is stored in the memory of the
SQL/MX executor.
Automatic recompilation incurs a performance cost because it requires the query
execution plan to be regenerated at run time and stored in memory. Automatically
recompiled query plans are not saved for subsequent executions of the same program
or for multiple concurrent executions of the same program. Because of this limitation,
automatic recompilation might be unsuitable for some production environments.
Causes of Automatic Recompilation
By default, automatic recompilation is enabled for all SQLJ programs. Automatic
recompilation occurs if:
•
The value of a DEFINE or the timestamp of a table changes, and the similarity
check fails or is disabled. For more information, see Similarity Check on page 4-26.
•
A DML statement was not compiled when you explicitly SQL compiled the module
definition because the table did not exist or was unavailable during customization.
For more information, see Causes of Dynamic Execution on page 4-2.
•
A transaction mode changes because of a SET TRANSACTION statement. For
more information, see Setting Attributes for Transactions on page 4-43.
Note. If the plan uses OLT optimization, the number of partitions does not affect the
similarity check. For more information about OLT optimization, see the SQL/MX Query
Guide.