All Products
Search
Document Center

PolarDB:Limits on parallel queries and inconsistencies between the results of parallel execution and serial execution

Last Updated:Mar 18, 2024

This topic describes the limits on parallel queries and the possible inconsistencies between the results of parallel execution and serial execution.

Limits on parallel queries

PolarDB continuously improves the parallel query feature. This feature cannot improve performance in the following situations:

  • Queries on non-Innodb tables.

  • Queries that use full-text indexes.

  • Stored procedures, which must be executed by the leader.

  • Tables that are scanned by using INDEX-MERGE joins.

  • Queries in serializable transactions.

  • INSERT ... SELECT and REPLACE ... SELECT statements in transactions when the isolation level is Repeatable Read.

Inconsistencies between the results of parallel execution and serial execution

  • The number of error messages may increase.

    Assume that you use serial execution for statements and error messages occur. If you use parallel execution for the same statements, more error messages may be returned.

  • Precision issues may occur.

    For serial execution, no intermediate results need to be stored. For parallel execution, you may need to store intermediate results. If the intermediate results are floating-point numbers, the precision of the floating-point numbers may be different from that of parallel execution. This may result in differences in the results of parallel execution and serial execution.

  • The size of network packets or intermediate results exceeds the upper limit that is specified by the max_allowed_packet parameter.

    For serial execution, no intermediate results are produced. For parallel execution, intermediate results may be produced. If the size of the intermediate results exceeds the upper limit that is specified by the max_allowed_packet parameter, an error message may be returned. To resolve this issue, you can increase the value of the max_allowed_packet parameter. For more information about how to modify parameters, see Specify cluster and node parameters.

  • The order of the result sets for parallel execution may be different from that for serial execution.

    If the SELECT ... LIMIT n statement that does not contain the ORDER BY keyword is executed in parallel, the order of the returned result sets may be inconsistent with the execution order. Multiple workers are executed simultaneously. Therefore, the execution speed of the workers is uncertain during each execution. After the leader retrieves enough data, the final results are returned. As a result, the order of the returned result sets may be inconsistent with the execution order.

  • The number of data records that have row locks is increased.

    If the SELECT ... FROM ... FOR SHARE statement is executed in parallel, InnoDB locks each row of data that is accessed. Therefore, the number of records that have row locks may be more than that in non-parallel execution cases. This phenomenon is normal in parallel execution cases.