HTREINIT is part of the batch-mode hash table wait family. Parallel batch-mode hash joins and aggregations share one hash table across threads (since SQL Server 2014), and some join strategies process their input in multiple passes or partial joins. HTREINIT is the threads synchronising before the shared hash table is reset for the next partial join.
Like its siblings, it shows up mostly on columnstore and batch-mode heavy workloads.
Is It a Problem?
Judge it exactly like the rest of the HT family: it measures how uneven the work was between parallel threads, not how expensive the join was. Near-zero HT time means balanced threads; growing time means the synchronisation points keep waiting for a straggler. HTREINIT specifically appearing means your plans involve multi-pass hash processing, which often points at hash operations spilling or partitioning because they are bigger than their memory grant.
It is usually the smallest of the HT* waits; it rarely leads the family.
Common Causes
- Batch-mode hash joins processing input in multiple partial passes, typically because the build input exceeded the memory grant.
- Data skew on the hash keys stretching each synchronisation point.
- High MAXDOP multiplying the coordination cost.
What To Do
- Check the biggest batch-mode queries for hash spills (warnings in the actual plan, or
sys.dm_exec_query_statsspill columns); multi-pass hashing often traces to undersized grants. - Fix the grant story: updated statistics, and on modern versions let batch-mode memory grant feedback settle in.
- Confirm and address thread skew via per-thread row counts in the plan, as with all HT* waits.
- Test lower MAXDOP where skew is inherent to the data.
How To See It
Rank it against everything else with Get-WaitStatistics, alongside the rest of the HT* family and the spill indicators.
Part of the SQL Server Wait Types Library.
Related deep dive: CXPACKET and CXCONSUMER Wait Types.
Leave a Reply