skip to content

In Amazon Redshift, what is a node slice and why does the total slice count govern parallelism?

level: middleimportance: must knowfreq 68%

answer

  1. A node is not one worker
  2. Memory and disk are split inside a node
  3. Node type fixes how many there are
  4. Steps end when the slowest one ends
  5. Load file count should be a multiple of it

basics

~20 s

A slice is a partition of a compute node's memory and disk that acts as an independent worker. Redshift spreads every table's rows across all slices and runs each plan segment once per slice, so total slices set the cluster's degree of parallelism.

solid answer

~50 s

Each Redshift compute node is divided into a fixed number of slices determined by its node type — a larger node type has more slices than a small one. Total cluster parallelism is `nodes × slices per node`. When you load a table, its distribution style decides which slice each row lands on, and every scan, filter, aggregation and join step then runs concurrently, once per slice, over the rows that slice owns. Two consequences dominate real tuning work. First, a step finishes when its **slowest** slice finishes, so if one slice holds far more rows than the others the cluster runs at roughly one slice's speed. Second, several operations are parallel *per slice* rather than per node — for example a load reads input files in parallel across slices, so the number of input files should be a multiple of the slice count. `STV_SLICES` maps slices to nodes.

code

sql · 4 lines
sql
-- Node-to-slice mapping for the current cluster
SELECT node, slice
FROM stv_slices
ORDER BY node, slice;

go deeper

for a junior

Know the vocabulary: compute nodes are divided into slices, and a table's rows are spread across all of them so scans run in parallel. You are unlikely to be asked to tune this yet.

for a middle

Be able to compute total parallelism as nodes times slices per node, explain that node type fixes the per-node count, and connect it to the standard advice about splitting load files and watching per-slice row counts.

for a senior

Demonstrate that you diagnose at slice granularity: read per-slice timings and row counts, recognize a single hot slice pacing the whole step, and reason about per-slice memory grants and spilling.

for a principal

Own capacity planning in slices rather than nodes — how node type choice, resize targets and workload placement change effective parallelism, and when the answer is a different cluster shape rather than more of the same nodes.

## What a slice actually is A compute node in Amazon Redshift is not a single worker. It is subdivided into **slices**, and each slice receives a share of the node's memory and disk. A slice behaves like an independent mini-database: it owns a subset of every table's rows and executes the compiled plan segments the leader node sent, over its own data only. The number of slices per node is fixed by the **node type** — larger node types carry more slices than the small ones — so the cluster's total parallelism is simply the number of compute nodes multiplied by the slices per node. This is the unit that almost every other Redshift tuning answer refers back to. "Parallel" in Redshift means *per slice*, not per node and not per core. ## How rows land on slices When data is written, the table's distribution style decides slice placement: rows may be hashed on a distribution column, dealt round-robin, or a full copy of the table may be placed on the first slice of every node. Whatever the mechanism, once the rows are placed, every scan step runs concurrently on all slices, and each slice reads only its own blocks. ## Why the slice count sets the pace A parallel step ends when its slowest participant ends. If a table's rows are spread evenly, sixteen slices each do a sixteenth of the work and the step takes a sixteenth of the serial time. If one slice holds ten times as many rows as its peers — a skewed distribution key, or a key with a dominant value — the other fifteen slices finish early and idle while one grinds through its share. The cluster is then delivering roughly single-slice throughput while you pay for sixteen. `SVV_TABLE_INFO` exposes per-table skew indicators, and `STV_BLOCKLIST` lets you count blocks per slice for a table. (Choosing the distribution style that avoids this is its own topic; here the point is simply that slice-level imbalance, not node-level imbalance, is what you measure.) ## Slice-parallel operations you notice - **Loading from S3.** A load reads input files in parallel across slices. One large input file that cannot be split is read by a single slice while the rest of the cluster waits; splitting the input into a number of files that is a multiple of the total slice count keeps every slice busy. This is the most frequently cited practical consequence of slice arithmetic. - **Unloading to S3.** The reverse also runs per slice, writing multiple output files in parallel and bypassing the leader node entirely. - **Memory grants.** Query memory is divided among slices, so per-slice memory — not total cluster memory — determines whether a hash table or sort fits before it spills to disk. - **Replicated tables.** A table distributed to every node is materialized on the first slice of each node, not on all slices. ## Slice counts change when the cluster changes Resizing a cluster changes the total slice count, and the data must be remapped across the new arrangement. After an elastic resize, Redshift may temporarily place more than one logical data partition on a slice and rebalance in the background, so query performance ramps up rather than jumping instantly. Moving to a different node type changes slices per node as well as node count, which is why capacity planning is done in slices, not just in nodes. ## Serverless and RA3 On RA3 node types the authoritative data lives in Redshift Managed Storage with local SSD acting as a cache, but slices are unchanged: they still own logical partitions of each table and execute segments in parallel. Redshift Serverless hides node and slice counts behind RPU capacity, so slice arithmetic stops being something you tune directly — but the same execution model is running underneath. ## What an interviewer wants to hear Three things: that a slice is a share of a node's memory and disk acting as an independent worker; that total parallelism is nodes times slices per node and is fixed by node type; and that the practical rules everyone quotes — split your load files, watch per-slice skew, size memory per slice — all fall out of that one fact. Candidates who describe parallelism as "one thread per node" have not internalized the model.

  • Why does splitting a load's input files to a multiple of the cluster's slice count matter?
    Redshift reads input files in parallel across slices, one file at a time per slice. A single unsplittable file is read by one slice while every other slice idles. Splitting the input into a multiple of the total slice count gives every slice an equal number of files, so the load finishes in roughly one file's time rather than the whole dataset's.
  • If one slice holds far more rows than the others, what do you actually observe at query time?
    Steps take as long as the busiest slice, so elapsed time barely improves when you add nodes, and per-step timings show one slice with a far higher row count or duration than its peers. Table-level skew indicators confirm it. The fix is a distribution choice that spreads the dominant key values, not a bigger cluster.
  • Does query memory scale with the cluster's total RAM or with something smaller?
    With per-slice memory. A query's memory grant is divided among slices, so a hash table or sort must fit within one slice's share or it spills to disk. That is why a cluster with plenty of aggregate RAM can still spill, and why memory-per-slice is the number to reason about.

A compute node is a shipping warehouse and its slices are the loading bays: adding warehouses helps only if every bay in every warehouse gets a comparable pile of freight.

saying these in an interview costs you the question

  • Believing each node runs a query as a single thread
  • Thinking slice count is configurable per table
  • Assuming every node type has the same number of slices
  • Measuring skew at node level instead of slice level
  • Sizing query memory from total cluster RAM

context

resolving links…