Parallel query issue

[ukzz1]

Hi, Hi, I encountered an issue during testing. Some data synchronization scenarios use order by limit, but I found that if parallel queries are enabled, the query takes 10x or more slower. I think it should be related to parallel scan, below is the reproduced image.

[willhan123]

thanks !
we will test it

[Yangxingyu3028]

The main time consumption of this query in parallel queries is on the exchange operator, i.e., the sender and receiver in the execution plan. Currently, the exchange operator of this version has performance problems when handling intensive data transmission, involving issues such as additional memory copying and locking. We will fix this problem in subsequent updates.

[7yi65]

Queries with /+PARALLEL(0)/: Parallelism is disabled, and a single - thread full - table scan is performed (the execution plan shows type = ALL, and Extra contains Using filesort). It skips the additional overhead of parallelism (such as process communication and result merging). Although it's a full - table scan, the offset + sorting logic is simple, and the actual execution is faster. Queries without the parallel hint: Parallelism is enabled (Parallel scan (4 workers)), which incurs overheads like process communication and merge sorting. In the scenario of a large offset (LIMIT 2900000), this "cancels out" the advantages of parallelism, and the execution is slower (34.82 seconds).

[ukzz1]

yes, it's similar to what I guessed. When parallel query is enabled, each worker thread may have to return 2900010 rows of data to the receiver, and the receiver may also need to perform a merge operation, so the query is slower than the native one.