(Republishing, or using this info in a commercial product/website, is prohibited without permission. All other uses are permitted. If in doubt, please ask.)
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 at the end 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:
2014
Removed in SQL Server version:
N/A
Extended Events wait_type value:
Maps to the HASH_TABLE_DELETE map_value in sys.dm_xe_map_values.
The map_key value in sys.dm_xe_map_values is 195 in 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:
I have heard of this wait type occurring during updates to clustered columnstore indexes when the index has a lot of deleted rows per rowgroup, which can be fixed by rebuilding the index.
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 new 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):
- Waiting for access to the shared hash table, in this case while deleting 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):
- SOS_Task::PostWait+0x6f
WaitableBase::Wait+0x178
CSyncPoint::WaitAtNthGate+0x1c1
CSyncPoint::Wait+0x152
CBpSpillProcessor::CleanUpNextIterator+0x1e3
CBpSpillProcessor::Main+0x31c
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