EXECSYNC is a parallelism wait recorded when the threads of a parallel plan wait for a shared construct to be built by a single thread. Unlike CXPACKET, which covers the exchange iterators moving rows between threads, EXECSYNC covers the supporting structures: bitmaps for star join filtering, spools, large binary objects, and similar helpers that get built once and then used by all threads.
While one thread builds the construct, the rest of the gang waits here.
Is It a Problem?
Rarely; it has not been a noticeable contention point and is commonly filtered as benign. Some EXECSYNC is simply the shape of plans that use bitmaps and spools. As with the whole parallelism family, do not cut MAXDOP just to suppress the wait.
If it grows conspicuously, the interesting question is which plans lean on single-threaded construct builds, spools especially, since an eager spool in a parallel plan can serialise real work behind one thread.
Common Causes
- Parallel plans building bitmaps for hash join filtering (star schema queries).
- Spools (eager or lazy) in parallel plans, built single-threaded.
- Large object handling inside parallel execution.
What To Do
- Filter it from routine analysis; our
Get-WaitStatisticsscript treats it as benign. - If a specific query regresses with high
EXECSYNC, check its plan for spools; removing the need for a spool (better indexes, rewritten predicates) removes the serialisation point. - Leave parallelism settings out of it unless the broader CX picture says otherwise.
How To See It
Rank waits with Get-WaitStatistics, where it is filtered by default. In query-level troubleshooting, its presence points at construct builds inside the plan.
Part of the SQL Server Wait Types Library.
Related deep dive: CXPACKET and CXCONSUMER Wait Types.
Leave a Reply