CXROWSET_SYNC is a wait recorded during a parallel range scan, when a worker thread needs exclusive access to the scan’s shared parent rowset to coordinate with the other child threads. In a parallel scan, threads grab ranges of pages from a shared structure as they finish their previous range; this wait is the brief queue at that shared structure.
It is parallelism plumbing, the same family as CXPACKET, just at the scan level rather than the exchange level.
Is It a Problem?
No, not as a contention point in its own right. It has not been observed as a meaningful bottleneck; the synchronisation it measures is momentary. Its presence simply confirms parallel scans are happening.
The useful question is the one behind it: should those scans be parallel, and should they be scans at all? A workload dominated by parallel scans on an OLTP server usually has an indexing or parallelism-threshold problem, and other waits (CXPACKET, PAGEIOLATCH_SH) will be saying so more loudly.
Common Causes
- Normal parallel range scans in reporting, ETL, or maintenance workloads.
- Trivial queries going parallel because
cost threshold for parallelismis still at the default of 5. - Missing indexes forcing large scans that then parallelise.
What To Do
- Nothing for the wait itself. If it is visible, look at the workload pattern around it.
- If parallel scans are unwanted, raise
cost threshold for parallelismand set MAXDOP appropriately for the hardware. - If the scans themselves are the issue, find the queries driving them and index the predicates so they seek instead.
- Confirm the bigger picture with the full wait profile;
CXROWSET_SYNCalone should never drive a change.
How To See It
Rank it against everything else with Get-WaitStatistics. Expect it as a minor line item on any server running parallel scans, and read it alongside CXPACKET and CXCONSUMER.
Part of the SQL Server Wait Types Library.
Related deep dive: CXPACKET and CXCONSUMER Wait Types.
Leave a Reply