blob: 8b3fb2e844bce3950938d44b0ef69d13695f9c65 [file] [log] [blame]
<table class="table table-bordered">
<thead>
<tr>
<th class="text-left" style="width: 20%">Key</th>
<th class="text-left" style="width: 15%">Default</th>
<th class="text-left" style="width: 10%">Type</th>
<th class="text-left" style="width: 55%">Description</th>
</tr>
</thead>
<tbody>
<tr>
<td><h5>taskmanager.runtime.hashjoin-bloom-filters</h5></td>
<td style="word-wrap: break-word;">false</td>
<td>Boolean</td>
<td>Flag to activate/deactivate bloom filters in the hybrid hash join implementation. In cases where the hash join needs to spill to disk (datasets larger than the reserved fraction of memory), these bloom filters can greatly reduce the number of spilled records, at the cost some CPU cycles.</td>
</tr>
<tr>
<td><h5>taskmanager.runtime.large-record-handler</h5></td>
<td style="word-wrap: break-word;">false</td>
<td>Boolean</td>
<td>Whether to use the LargeRecordHandler when spilling. If a record will not fit into the sorting buffer. The record will be spilled on disk and the sorting will continue with only the key. The record itself will be read afterwards when merging.</td>
</tr>
<tr>
<td><h5>taskmanager.runtime.max-fan</h5></td>
<td style="word-wrap: break-word;">128</td>
<td>Integer</td>
<td>The maximal fan-in for external merge joins and fan-out for spilling hash tables. Limits the number of file handles per operator, but may cause intermediate merging/partitioning, if set too small.</td>
</tr>
<tr>
<td><h5>taskmanager.runtime.sort-spilling-threshold</h5></td>
<td style="word-wrap: break-word;">0.8</td>
<td>Float</td>
<td>A sort operation starts spilling when this fraction of its memory budget is full.</td>
</tr>
</tbody>
</table>