A BigQuery slot is a unit of computational capacity required to execute SQL queries. BigQuery automatically calculates how many slots are required by each query, depending on query size and complexity.
See the quota policy for queries for the per-project slot quota.
Most users find the default slot capacity more than sufficient. Access to more slots does not guarantee faster per-query performance. However, a larger pool of slots might improve performance of very large or very complex queries, as well as performance of highly concurrent workloads. To check how many slots your account uses, see BigQuery monitoring.
BigQuery automatically manages your slots quota based on customer history, usage, and spending. For customers who require consistent monthly expenditures on analytics spending, BigQuery offers flat-rate pricing.
Query execution using slots
When BigQuery executes a query job, it converts the declarative SQL statement into a graph of execution, broken up into a series of query stages, which themselves are composed of more granular sets of execution steps. BigQuery leverages a heavily distributed parallel architecture to run these queries, and the stages model the units of work that many potential workers may execute in parallel. Stages communicate with one another by using a fast distributed shuffle architecture, which has been discussed in more detail elsewhere.
BigQuery query execution is dynamic, which means that the query plan can be modified while a query is in flight. Stages that are introduced while a query is running are often used to improve data distribution throughout query workers.
BigQuery slots execute individual units of work at each stage of the query. For example, if BigQuery determines that a stage's optimal parallelization factor is 10, it requests 10 slots to process that stage.
Query execution under slot resource economy
If a query requests more slots than currently available, BigQuery queues up individual units of work and waits for slots to become available. As forward progress on query execution is made, and as slots free up, these queued up units of work get dynamically picked up for execution.
BigQuery can request any number of slots for a particular stage of a query. The number of slots requested is not related to the amount of capacity you purchase, but rather an indication of the most optimal parallelization factor chosen by BigQuery for that stage. Units of work queue up and get executed as slots become available.
When query demands exceed slots you committed to, you are not charged for additional slots, and you are not charged for additional on-demand rates. Your individual units of work simply queue up.
- A query stage requests 2,000 slots, but only 1,000 are available.
- BigQuery consumes all 1,000 slots and queues up the other 1,000 slots.
- Thereafter, if 100 slots finish their work, they dynamically pick up 100 units of work from the 1,000 queued up units of work. 900 units of queued up work will remain.
- Thereafter, if 500 slots finish their work, they dynamically pick up 500 units of work from the 900 queued up units of work. 400 units of queued up work will remain.
- And so on.
Fair scheduling in BigQuery
BigQuery leverages fair scheduling to allocate resources among competing queries. This means that every query has equal access to all available slots at any time, and capacity is dynamically and automatically re-allocated among active queries as each query's capacity demands change. Queries complete and new queries get submitted for execution under the following conditions:
- Whenever a new query is submitted, capacity is automatically re-allocated across executing queries. Individual units of work can be gracefully paused, resumed, and queued up as more capacity becomes available to each query.
- Whenever a query completes, capacity consumed by that query automatically becomes immediately available for all other queries to use.
- Whenever a query's capacity demands change due to changes in query's dynamic DAG, BigQuery automatically re-evaluates capacity availability for this and all other queries, re-allocating and pausing slots as necessary.
Depending on complexity and size, a query might not require all the slots it has the right to, or it may require more. BigQuery dynamically ensures that, given fair scheduling, all slots can be fully used at any point in time.