This topic describes the limits on parallel queries. This topic also describes the 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 system tables, and InnoDB tables.
  • Queries that use full-text indexes.
  • Stored procedures.
  • Recursive common table expressions (CTEs).
  • Window functions. The parallel query feature cannot be implemented on window functions, but can be implemented on the queries that use window functions.
  • Geographic information system (GIS) functions. The parallel query feature cannot be implemented on GIS functions, but can be implemented on the queries that use window functions.
  • Index merges.
  • Queries in serializable transactions.

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, error messages may be returned for each worker thread. This may cause an increase in the total number of error messages.

  • The 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 for the intermediate results may be different from that for the final results 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 cluster parameters, see Specify cluster parameters.

  • The order of the result sets is different.

    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 simultaneously executed. Therefore, the execution speed of the workers is uncertain during each execution. After the leader retrieves enough data, the 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 is a normal case.