Explain the internal working of morsel-driven parallelism in DuckDB?

Morsel-driven parallelism divides a query's work into many small, independent chunks, "morsels", of data (a portion of a row group, for instance), which are then dynamically assigned to whichever worker thread becomes available next, rather than statically dividing work into a fixed number of large chunks assigned up front.

The dynamic, work-stealing-style assignment is the key detail: if one thread finishes its current morsel faster than another (because of data skew, an uneven filter selectivity, or simply variable system load), it simply pulls the next available morsel from the shared queue rather than sitting idle waiting for a statically pre-assigned chunk to become relevant. This keeps CPU cores well-utilized even when the actual work per morsel isn't perfectly uniform, which is a common and hard-to-predict situation in real analytical workloads.

Combined with vectorized execution, where each morsel is itself processed in cache-friendly batches rather than row by row, morsel-driven parallelism is what lets DuckDB scale effectively across the multiple cores of a single modern machine without needing the heavier coordination machinery a distributed, multi-node system requires.