HTBUILD

(Republishing, or using this info in a commercial product/website, is prohibited without permission. All other uses are permitted. If in doubt, please ask.)

(Back to main page…)

Description:

This wait type (and the other HT* waits) is when a thread is waiting for access to the shared hash table used during batch-mode processing. SQL Server 2012 used to use a hash table per thread and SQL Server 2014 now uses a shared hash table. This change was made to reduce the amount of memory required for the hash table, but comes at the expense of these waits when synchronizing access to the hash table. Typically these waits occur when queries involve columnstore indexes, but they can also occur without columnstore indexes being involved if a hash operator runs in batch mode (as shown in one of the call stacks below).

Books Online description: Occurs with parallel batch-mode plans when synchronizing the building of the hash table on the input side of a hash join/aggregation. If waiting is excessive and cannot be reduced by tuning the query (such as adding indexes), consider adjusting the cost threshold for parallelism or lowering the degree of parallelism.)

Questions/comments on this wait type? Click here to send Paul an email, especially if you have any information to add to this topic.

Added in SQL Server version:

2012

Removed in SQL Server version:

N/A

Extended Events wait_type value:

Maps to the HASH_TABLE_BUILD map_value in sys.dm_xe_map_values (thanks to Jonathan’s post here).

The map_key value in sys.dm_xe_map_values is 193 in 2012 and 2014 RTM. After 2014 RTM, you must check the DMV to get the latest value as some map_key values have changed in later builds.

Other information:

General guidance for this and other HT* waits, based on conversations with the SQL Server team: these waits are not really showing how expensive the operation is, but more how much skew there was in the data being processed by the various threads (with more skew meaning a longer operation). If there is perfect balance, there should be near zero wait time for these waits. The higher the degree of parallelism, and the higher the skew between threads, the higher the accumulated wait time will be for these waits. About the only sensible thing you can do to alleviate these waits is to make sure there is not a lot of data lying around in delta stores. Don’t knee-jerk and lower MAXDOP as that will likely slow things down.

Known occurrences in SQL Server (list number matches call stack list):

  1. Waiting for access to the shared hash table, in this case while building a hash table as part of a batch-mode hash aggregate involving only rowstore tables

And other, similar call stacks.

Abbreviated call stacks (list number matches known occurrences list):

  1. SOS_Task::PostWait+0x6f
    WaitableBase::Wait+0x178
    CSyncPoint::WaitAtNthGate+0x1c1
    CSyncPoint::Wait+0x161
    CBpQScanHashAggNew::ProcessInput+0x27b
    CBpQScanHashAggNew::PbsGetForOriginalInputs+0x21
    CBpSpillProcessor::Main+0x113
    CBpQScanHashAggNew::BpGetNextBatch+0x52
    CBpQScan::GetNextBatch+0x6f
    CBpQScanProject::BpGetNextBatch+0x14
    CQScanBatchHelper::GetRow+0x94
    CQScanXProducerNew::GetRowHelper+0x73
    FnProducerOpen+0x5b
    FnProducerThread+0x802
    SubprocEntrypoint+0xd25
    SOS_Task::Param::Execute+0x232
    SOS_Scheduler::RunTask+0xb5