Table Calc Compute Using — Set compute using / addressing and partitioning correctly (intro-to-standard) - Tableau

SECTION 1

Historical Context & Motivation

Before modern visual analytics platforms existed, analysts who needed running totals, moving averages, or rank calculations within subsets of data had to write verbose SQL window functions or resort to post-hoc spreadsheet manipulations. The fundamental challenge was always the same: how do you specify which rows a calculation should traverse (the window frame) and which dimensions should reset the calculation (the partition boundary)? Tableau introduced table calculations as a way to bring these capabilities directly into the visualization layer, abstracting the underlying complexity while preserving the analyst's control over computation direction and scope.

2003 • SQL Window Functions Standardized

SQL:2003 formalized OVER(PARTITION BY ... ORDER BY ...) clauses, giving database engineers a declarative way to express computations across row sets. This concept of partitioning and ordering became the intellectual foundation for visual analytics tools.

2008 • Tableau Introduces Quick Table Calculations

Tableau introduced drag-and-drop table calculations with automatic 'Compute Using' defaults, enabling users to add running totals and percent-of-total without writing code. However, the automatic defaults often produced unexpected results when views changed.

2013 • Addressing & Partitioning UI Refined

Tableau 8.x significantly improved the 'Edit Table Calculation' dialog, introducing clearer language around addressing (the dimensions the calculation moves along) and partitioning (the dimensions that define independent scopes). This shift moved power users toward explicit control.

2020 • Specific Dimensions Becomes Best Practice

The Tableau community converged on a best practice: always use 'Specific Dimensions' rather than the convenience shortcuts (Table Across, Table Down, etc.). This approach makes calculations resilient to layout changes and explicitly documents intent.

The core question this concept addresses is deceptively simple: when Tableau evaluates a table calculation like RUNNING_SUM(SUM([Sales])), which direction does it accumulate, and where does it restart? Getting this wrong produces silently incorrect numbers—a far more dangerous outcome than an error message. Understanding Compute Using (addressing and partitioning) is the key to reliable, portable table calculations.

SECTION 2

Core Principles & Definitions

Every Tableau table calculation operates within a conceptual frame defined by two complementary sets of dimensions. Imagine a spreadsheet where you have rows grouped by Region and columns grouped by Quarter. A running total might accumulate across quarters within each region, or it might accumulate down regions within each quarter. The difference lies entirely in how the dimensions are divided between addressing and partitioning. These two roles are mutually exclusive and collectively exhaustive: every dimension in the view must be assigned to exactly one.

Addressing (Compute Along)

The set of dimensions the calculation moves through. Addressing defines the direction of traversal—the cells the function iterates over when computing values like RUNNING_SUM or INDEX.

Partitioning (Scope Boundaries)

The set of dimensions that define independent groups. The calculation restarts within each unique combination of partitioning dimension values, analogous to PARTITION BY in SQL window functions.

Compute Using Presets

Tableau offers shortcuts like 'Table (across)', 'Table (down)', 'Pane (across down)', etc. These are layout-relative—they depend on how dimensions are arranged on Rows and Columns shelves and change behavior when the layout changes.

Specific Dimensions (Explicit Control)

The recommended approach: manually select which dimensions are addressing fields. This makes the calculation layout-independent—moving a pill from Rows to Columns will not alter the result.

Sort Order Within Addressing

When using Specific Dimensions, the order of addressing fields matters. It determines the sequence in which cells are visited. Reordering addressing dimensions is analogous to changing the ORDER BY clause in a SQL window function.

✦

KEY TAKEAWAY

Think of addressing and partitioning like a for-loop over a two-dimensional array. The partitioning dimensions define the outer loop—each unique combination starts a fresh computation. The addressing dimensions define the inner loop—the direction the function accumulates or iterates. If you move a dimension from the inner loop to the outer loop, you change the computation from traversing that dimension to restarting at each of its values.

SECTION 3

Visual Explanation — Addressing vs. Partitioning

This cross-tab shows RUNNING_SUM(SUM([Sales])) with Quarter as addressing (cyan arrows show accumulation direction) and Region as partitioning (dashed violet borders show each independent scope). The running sum restarts for each region.

In the diagram above, the running sum for the East region starts at 100 (Q1), then adds 150 to become 250 (Q2), adds 150 more to reach 400 (Q3), and adds 150 again to end at 550 (Q4). The critical observation is that when the calculation encounters the West region, it starts fresh at 200—it does not continue from East's final value of 550. This restart behavior is entirely determined by Region being a partitioning dimension. If we moved Region from partitioning to addressing, the calculation would accumulate across all cells without restarting, producing a single grand running total that traverses all region-quarter combinations in sequence.

SECTION 4

How Compute Using Works Under the Hood

Table calculations in Tableau execute after the underlying query returns an aggregate result set. The Tableau engine first evaluates all measures at the granularity defined by the dimensions in the view, producing a virtual table of aggregated values. The table calculation then operates as a second pass over this virtual table, similar to how a SQL window function processes an already-aggregated result set. Understanding this two-pass architecture is essential because it explains why table calculations can reference SUM([Sales]) but cannot independently filter or group data—they are constrained to the shape of the view.

The Addressing–Partitioning Split as Set Theory

DIMENSION PARTITION RULE

D_view = D_addressing ∪ D_partitioning, where D_addressing ∩ D_partitioning = ∅

D_view is the set of all dimensions in the visualization. Every dimension must be assigned to exactly one role: addressing or partitioning. The two sets are disjoint and their union equals the full dimension set.

WINDOW FUNCTION ANALOGY

FUNC(agg) OVER (PARTITION BY D_partitioning ORDER BY D_addressing)

This SQL analogy maps directly: the partitioning dimensions become the PARTITION BY clause, and the addressing dimensions (with their order) become the ORDER BY clause. Tableau's RUNNING_SUM corresponds to SUM() OVER (...ROWS UNBOUNDED PRECEDING), while INDEX() maps to ROW_NUMBER().

Presets vs. Specific Dimensions

The Compute Using presets—Table (across), Table (down), Pane (across down), Cell—are syntactic sugar that dynamically assigns dimensions to addressing based on their current shelf placement. Table (across) means 'address along whichever dimensions are on Columns,' and Table (down) means 'address along whichever dimensions are on Rows.' The danger is immediately apparent: if a colleague rearranges the pills on the shelves, the calculation's behavior changes silently. Specific Dimensions eliminates this fragility by binding the calculation directly to named fields, making it layout-independent. The cost is a slightly more verbose configuration, but the gain in reliability and maintainability is substantial—especially in workbooks shared across teams.

💡

SQL Developer's Shortcut

If you already think in SQL window functions, here's the translation: the dimensions you check in the 'Specific Dimensions' list become your ORDER BY (addressing). Everything you leave unchecked becomes your PARTITION BY (partitioning). The reorder arrows in the dialog correspond to changing the column order in ORDER BY.

SECTION 5

Compute Using Modes — Detailed Classification

Tableau provides several preset modes and the fully explicit 'Specific Dimensions' mode. Understanding when each is appropriate—and recognizing the risks of the layout-dependent modes—is a crucial skill for building robust dashboards. The following diagram and table provide a systematic classification.

Decision tree showing the two paths for configuring Compute Using. The left branch (preset modes) is layout-dependent and fragile. The right branch (Specific Dimensions) is explicit and robust. Checked dimensions become addressing; unchecked dimensions become partitioning.

Mode	Addressing Is Determined By	Layout-Dependent?	Recommended Use
`Table (across)`	Dimensions on Columns shelf, left to right	Yes	Quick exploration only
`Table (down)`	Dimensions on Rows shelf, top to bottom	Yes	Quick exploration only
`Table (across then down)`	All Columns dims first, then all Rows dims	Yes	Quick exploration only
`Pane (across down)`	Inner Columns then inner Rows dims within each pane	Yes	Quick exploration only
`Cell`	No addressing—each cell is its own partition	Partial	TOTAL or WINDOW_AVG on entire view
`Specific Dimensions`	Explicitly selected dimension names	No ✓	Always — production dashboards

Comparison of all Compute Using modes in Tableau

SECTION 6

Worked Example — Running Sum with Specific Dimensions

Consider a Tableau view with three dimensions: [Region] on Rows, [Category] on Rows (inner), and [Quarter] on Columns. The measure is SUM([Sales]). We want to compute a running sum of sales that accumulates across quarters within each Region–Category combination.

Configuring RUNNING_SUM with Specific Dimensions

1
Step 1 — Identify All Dimensions in the View

List every dimension present in the viz: [Region], [Category], [Quarter]. These three constitute D_view. Every one of them must be assigned to either addressing or partitioning.

D_view = {Region, Category, Quarter}
2
Step 2 — Define the Addressing Direction

We want the running sum to accumulate across quarters. Therefore, [Quarter] is our addressing dimension. In the Edit Table Calculation dialog, select 'Specific Dimensions' and check only the [Quarter] checkbox.

D_addressing = {Quarter} ☑
3
Step 3 — Identify Partitioning (by Exclusion)

Every dimension NOT checked becomes a partitioning dimension automatically. Since [Region] and [Category] are unchecked, they form the partitioning set. The calculation will restart for each unique (Region, Category) pair.

D_partitioning = {Region, Category} ☐
4
Step 4 — Trace the Computation for One Partition

Take the partition (East, Furniture). Suppose SUM([Sales]) for Q1 = 120, Q2 = 80, Q3 = 200, Q4 = 150. The running sum proceeds: Q1 → 120, Q2 → 120 + 80 = 200, Q3 → 200 + 200 = 400, Q4 → 400 + 150 = 550.

Running Sum (East, Furniture): 120, 200, 400, 550
5
Step 5 — Verify Layout Independence

Now drag [Category] from Rows to Columns. Because we used Specific Dimensions (not a preset), the calculation still addresses [Quarter] and partitions by {Region, Category}. The values remain exactly 120, 200, 400, 550 for (East, Furniture). Had we used 'Table (across),' the calculation would have changed to address across [Category, Quarter] on Columns—producing completely different numbers.

Layout change: values unchanged ✓ (Specific Dimensions confirmed)

SECTION 7

Strengths, Limitations & Common Pitfalls

Aspect	Strengths	Limitations / Pitfalls
Specific Dimensions	Layout-independent; self-documenting; safe for shared workbooks; survives pill rearrangement.	Requires the user to understand which dimensions exist in the view; must be updated if new dimensions are added to the visualization.
Presets (Table, Pane, Cell)	Fast to configure; useful during rapid prototyping; no need to know dimension names.	Fragile—layout changes silently alter results; difficult to debug; poor for team collaboration.
Addressing Order	Full control over traversal sequence; enables multi-dimensional running totals (e.g., across months then across categories).	Reordering produces different results—easy to misconfigure if the analyst does not trace the accumulation path carefully.
Adding Dimensions to the View	With Specific Dimensions, new dims default to partitioning—usually the safe behavior.	With presets, adding dims to Rows/Columns can change what 'across' or 'down' means. Also, if a new dim should be addressing, the user must manually check it.

Strengths and limitations of Compute Using configuration approaches

✦

KEY TAKEAWAY

Think of preset Compute Using modes like relative file paths in code (e.g., ../../data.csv)—they work until someone reorganizes the directory structure. Specific Dimensions is like using an absolute path or a named constant: it always resolves to the same thing regardless of context. In production systems, explicit beats implicit.

SECTION 8

Connection to Advanced Table Calculation Patterns

Once you have a solid understanding of addressing and partitioning, you can compose more sophisticated calculations. Nested table calculations—where one table calc wraps another—require you to set Compute Using independently for each layer. For instance, computing the year-over-year percent change of a running total involves a RUNNING_SUM addressed along Month (inner) and a LOOKUP addressed along Year (outer). Each function's Compute Using is configured separately in the Edit Table Calculation dialog, and misconfiguring either one corrupts the final result.

Concept	This Lesson (Intro-to-Standard)	Advanced Extensions
Single table calc	One function, one Compute Using configuration (e.g., RUNNING_SUM addressed along Quarter)	Nested table calcs: inner and outer functions each with independent Compute Using
Dimension scope	Only dimensions already in the view participate in addressing/partitioning	LOD expressions (FIXED, INCLUDE, EXCLUDE) can alter the grain before the table calc executes
Addressing order	Manual reorder in dialog; single traversal path	Custom sort expressions (SORT within the calc) or computed sort fields for dynamic ordering
Debugging	Use INDEX() to verify traversal order visually	Use SIZE(), FIRST(), LAST() combined with conditional highlighting to validate partition boundaries

Introductory concepts vs. advanced extensions

💡

Debugging Tip

When in doubt, place INDEX() and SIZE() as separate pills on the view with the same Compute Using settings as your target calculation. INDEX() shows the traversal position within each partition, and SIZE() shows how many cells are in the partition. If INDEX() restarts where you don't expect it to, your partitioning dimensions are wrong.

SECTION 9

Practice Problems

Question 1: CONCEPTUAL

A Tableau view has three dimensions: [Year], [Region], and [Product]. If you configure RUNNING_SUM(SUM([Profit])) with Specific Dimensions and check only [Year], what are the addressing and partitioning sets? What does it mean operationally?

Show answer

Addressing = {Year}, Partitioning = {Region, Product}. Operationally, the running sum accumulates across years. It restarts for each unique (Region, Product) combination. For example, the running sum for (East, Chairs) would be independent of the running sum for (East, Tables) or (West, Chairs). Every partition gets its own isolated running total across the Year dimension.

Question 2: BASIC CALCULATION

Given a partition (West, Technology) with SUM([Sales]) values of Q1=300, Q2=450, Q3=200, Q4=500, compute the RUNNING_SUM values for each quarter. Then compute what RANK_UNIQUE(SUM([Sales])) would produce for the same partition with default ascending order.

Show answer

RUNNING_SUM: Q1 = 300, Q2 = 300 + 450 = 750, Q3 = 750 + 200 = 950, Q4 = 950 + 500 = 1450. For RANK_UNIQUE with ascending order (smallest = rank 1): Q3 = rank 1 (200 is smallest), Q1 = rank 2 (300), Q2 = rank 3 (450), Q4 = rank 4 (500 is largest). Note that RANK_UNIQUE in Tableau defaults to competition ranking with descending order, so in Tableau's default: Q4 = 1, Q2 = 2, Q1 = 3, Q3 = 4. The key point is that addressing order doesn't affect rank—only the values matter—but the partition boundary determines which cells compete.

Question 3: INTERMEDIATE

You have a cross-tab with [Region] and [Category] on Rows (Region outer, Category inner) and [Quarter] on Columns. You configure RUNNING_SUM with 'Table (across).' A colleague then moves [Category] from Rows to Columns (making it the inner Column dimension). How does the calculation behavior change, and how would using Specific Dimensions have prevented the issue?

Show answer

With 'Table (across),' the addressing dimensions are whatever is on Columns. Originally, only [Quarter] is on Columns, so addressing = {Quarter} and partitioning = {Region, Category}. After the move, Columns contains [Quarter] (outer) and [Category] (inner), so addressing = {Quarter, Category} and partitioning = {Region} only. The running sum now accumulates across all Quarter×Category combinations within each Region, instead of restarting for each Category. The numbers change silently—no error is thrown. With Specific Dimensions set to check only [Quarter], the move would have no effect on the computation: [Category] would remain a partitioning dimension regardless of its shelf position. The calculation stays correct and the analyst avoids a potentially costly data error.

Question 4: APPLIED

You are building a dashboard for a retail chain. The view shows [Store], [Month], and [Product Line] as dimensions, with SUM([Revenue]) as the measure. The business requirement is: 'Show each store's cumulative revenue by month, with each product line tracked separately.' Write the table calculation expression and specify the exact Compute Using configuration (which dimensions to check, and the addressing order).

Show answer

The expression is RUNNING_SUM(SUM([Revenue])). In Compute Using, select 'Specific Dimensions' and check only [Month]. Leave [Store] and [Product Line] unchecked. This makes addressing = {Month} and partitioning = {Store, Product Line}. The running sum will accumulate month-by-month, restarting for each unique (Store, Product Line) pair—exactly matching the requirement that each store's product line gets its own cumulative track. The addressing order has a single dimension ([Month]), so ensure Month is sorted chronologically (default behavior for a date field). If Month were a string like 'Jan', 'Feb', etc., you might need to verify the sort order to avoid accumulating in alphabetical rather than calendar order.

Question 5: CRITICAL THINKING

Consider a nested table calculation: WINDOW_AVG(RUNNING_SUM(SUM([Sales]))). The view has [Region] on Rows and [Quarter] on Columns. You want RUNNING_SUM to accumulate across quarters (within each region), and then WINDOW_AVG to average those running sums across all regions (for each quarter). Describe the Compute Using configuration for each function, explain what happens if you accidentally set both to the same addressing, and discuss how you would verify correctness using INDEX() and SIZE().

Show answer

This is a nested table calculation requiring two independent Compute Using configurations. The inner function (RUNNING_SUM) should be addressed along [Quarter] with [Region] as partitioning—it accumulates across quarters within each region. The outer function (WINDOW_AVG) should be addressed along [Region] with [Quarter] as partitioning—it averages the running sum values across all regions for each quarter position. If both are set to address [Quarter], the WINDOW_AVG would average the running sums across quarters instead of across regions—producing a meaningless moving average of the running total rather than a cross-region comparison. To verify: place INDEX() with the same Compute Using as each function on separate rows of a text table. For the inner calc (addressed along Quarter), INDEX() should count 1, 2, 3, 4 within each region and SIZE() should equal the number of quarters. For the outer calc (addressed along Region), INDEX() should count 1, 2, 3 (if there are 3 regions) within each quarter and SIZE() should equal the number of regions. If these helper functions show unexpected patterns, the Compute Using is misconfigured.

SUMMARY

Lesson Summary

Summary

Table calculations in Tableau execute as a second pass over the aggregated result set, and their behavior is entirely governed by how dimensions are split between addressing (the dimensions the calculation moves along) and partitioning (the dimensions that define independent restart boundaries). These two sets are mutually exclusive and collectively exhaustive—every dimension in the view belongs to exactly one. The Compute Using setting controls this split, and Tableau offers both layout-relative presets (Table across, Table down, Pane, Cell) and the explicit Specific Dimensions mode.

The critical best practice is to always use Specific Dimensions for any calculation that will be published or shared. Preset modes are layout-dependent and will silently produce incorrect results when pills are rearranged on shelves. The analogy to SQL is precise: checked (addressing) dimensions correspond to ORDER BY, unchecked (partitioning) dimensions correspond to PARTITION BY. For debugging, use INDEX() and SIZE() with identical Compute Using settings to visualize traversal order and partition boundaries. This foundation prepares you for nested table calculations and integration with LOD expressions in advanced Tableau workflows.