Tableau Quiz: Performance Pitfalls
10 questions · exam conditions
0:00
Performance PitfallsQuestion 1 of 10

A dashboard has a filter control listing approximately two million customer identifiers. Opening the list is slow because Tableau must retrieve and present a very large domain. Users always enter exactly one known customer identifier and do not need to browse or select multiple customers.

Which redesign most appropriately removes the high-cardinality filter-control pitfall while preserving the stated requirement?

Convert Customer Identifier into a discrete table calculation and expose its computed values as a filter control.
Keep the complete customer list but configure it to show only relevant values for every other dashboard filter.
Place Customer Identifier on Detail so users can select the required customer directly from the rendered marks.
Use a free-entry parameter for one identifier and filter with a Boolean comparison against the customer field.
← Back to quizzes

Tableau Quiz

Tableau Quiz: Performance Pitfalls

Practice Performance Pitfalls in Tableau with focused quiz questions that help you check what you know, review explanations, and build confidence with test-style prompts.

What this quiz covers

This quiz focuses on Performance Pitfalls, giving you a quick way to practice the rules, question types, and explanations that matter most for Tableau.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

A dashboard has a filter control listing approximately two million customer identifiers. Opening the list is slow because Tableau must retrieve and present a very large domain. Users always enter exactly one known customer identifier and do not need to browse or select multiple customers.

Which redesign most appropriately removes the high-cardinality filter-control pitfall while preserving the stated requirement?

  1. Convert Customer Identifier into a discrete table calculation and expose its computed values as a filter control.
  2. Keep the complete customer list but configure it to show only relevant values for every other dashboard filter.
  3. Place Customer Identifier on Detail so users can select the required customer directly from the rendered marks.
  4. Use a free-entry parameter for one identifier and filter with a Boolean comparison against the customer field. (correct answer)
Explanation: When a filter control must load millions of distinct values, Tableau queries the full domain before rendering the dropdown — creating the slowdown you see here. The solution isn't to shrink or reorganize that list; it's to eliminate the list entirely. Since users always type exactly one known identifier rather than browse, a parameter is the right tool: it accepts free text input, never queries the data source for a domain, and renders instantly regardless of cardinality. You then create a calculated field like [Customer Identifier] = [Customer Parameter] and place it on the filter shelf as a Boolean. This perfectly matches the stated requirement — one entry, no browsing — and D describes exactly this approach. Choice A is a red herring. Converting the field to a discrete table calculation doesn't reduce the number of unique values Tableau must display; it still iterates over millions of records and presents them in a filter control, preserving the performance problem. Choice B — showing only relevant values — can reduce the list contextually, but it doesn't eliminate the domain-loading cost for a two-million-row identifier field. It also still forces users to scroll or search a large list, which conflicts with the "no browsing needed" requirement. Choice C puts the field on Detail so users click a mark on the viz. With two million customers, the rendered view would be an unnavigable sea of marks, making selection impractical and doing nothing to address filter-control performance. As a study tip, remember this pattern: high cardinality + single known value = parameter, not filter. Anytime you see a question pairing a massive domain with a precise, typed lookup, parameters are almost always the correct answer.

Question 2

A developer creates a hierarchy of Country, State, and City filter controls. Each control uses Only Relevant Values, and Country is placed in context. Country changes are infrequent, but State changes are common and repeatedly trigger a refresh of the large City domain.

Which assessment best reflects the performance tradeoff in this design?

  1. Placing Country in context guarantees that all State and City value lists remain cached for every later selection.
  2. The design improves selection accuracy, but the large dependent City domain may still require costly refreshes whenever State changes. (correct answer)
  3. Only relevant values are computed entirely from displayed marks, so the hierarchy adds no data-source query overhead.
  4. The City filter refresh occurs only when Country changes because ordinary State filters cannot affect dependent value domains.
Explanation: When you see a question about filter dependencies and context filters in Tableau, your mental model should center on how Tableau queries the data source to populate filter value lists — and what triggers those queries. Placing Country in context does one important thing: it creates a temporary table that scopes subsequent filters, improving query efficiency for filters that depend on Country. However, context filters do not magically cache every downstream value list forever. When a user changes State, Tableau still needs to re-query the data source to determine which City values are relevant to that new State selection. Because the City domain is large, this re-query is expensive and happens frequently — since State changes are described as common. Answer B correctly captures this tension: the "Only Relevant Values" approach ensures accurate, dependent filter lists, but the City domain refresh on every State change carries a real performance cost. Answer A is incorrect because context filters do not cache all downstream value lists indefinitely. Caching applies to the context query itself, not to every dependent filter's domain across all possible selections. Answer C misrepresents how "Only Relevant Values" works. This mode issues actual data-source queries to compute relevant members — it does not derive them purely from displayed marks (that's "Only Relevant Values" from the view, a different mechanism), so query overhead absolutely exists. Answer D is backwards. State filter changes do trigger City domain refreshes because City depends on State, not just on Country. Ordinary filters absolutely affect dependent value domains. Your study takeaway: context filters reduce redundant querying but don't eliminate downstream refresh costs — always trace the dependency chain when evaluating filter performance.

Question 3

A worksheet ranks approximately 500,000 product-location marks with a table calculation. A user-selected Region restriction is currently implemented as a table-calculation filter, even though the business requirement is to rank products only within the selected region.

Which change is both semantically appropriate and likely to improve performance?

  1. Move Region to Detail so the ranking calculation can process every region in one larger shared partition.
  2. Keep the table-calculation filter because hiding marks after ranking reduces the calculation's original partition size.
  3. Use a regular region filter before the ranking calculation so fewer marks enter the table-calculation stage. (correct answer)
  4. Make Region a parameter used only in the mark label so nonselected regions remain available but are not rendered.
Explanation: Whenever you see a question about table calculations and performance in Tableau, the core concept to keep in mind is the order of operations. Tableau processes filters in a specific sequence: regular (dimension) filters execute early, reducing the dataset before most calculations run, while table-calculation filters execute late — after the full computation has already occurred. This distinction is exactly what makes C the right answer. A regular Region filter acts as a dimension filter, meaning Tableau eliminates non-selected regions before computing the rank. With ~500,000 marks, filtering down to a single region first could reduce the working dataset dramatically — say, from 500,000 marks to 100,000 — so the ranking calculation partitions and processes far fewer rows. It's also semantically correct: you genuinely want to rank products only within the selected region, which a pre-calculation filter enforces by definition. Each distractor contains a specific trap. A is wrong because moving Region to Detail expands partitions rather than shrinking them — you'd be ranking across more marks, not fewer, defeating both goals. B is the most tempting distractor: it sounds plausible because table-calculation filters do "hide" marks visually, but the ranking calculation already ran on the full 500,000-mark partition before any hiding occurs, so performance doesn't improve and the rank values reflect the wrong scope. D is wrong because using a parameter in a label doesn't filter data at all — all marks still enter the calculation stage and the partition remains unchanged. The study tip here: always ask when a filter fires in Tableau's order of operations. If a filter runs after table calculations, it cannot reduce the computation cost or correct partition-level logic.

Question 4

A dashboard exposes 12 filter controls. Most are configured to show Only Relevant Values. Performance recordings show that changing one filter triggers several additional queries that refresh the value lists of other filters, even though only three controls participate in a meaningful selection hierarchy.

Which change is most likely to reduce interaction time while preserving the useful cascading behavior?

  1. Retain Only Relevant Values for the three dependent controls and simplify or remove the remaining visible filter controls. (correct answer)
  2. Convert every filter to a context filter so Tableau can generate all dependent value lists from one temporary table.
  3. Replace the data connection with an extract while leaving all filter controls and dependency settings unchanged.
  4. Implement each filter as a table calculation so the value lists can be evaluated after the database query completes.
Explanation: When a dashboard has multiple filters set to Only Relevant Values, Tableau issues a separate database query for each filter's value list whenever any selection changes. If most of those filters don't actually depend on each other, you're paying a performance cost for dependency behavior you don't need — this question asks you to identify the most surgical fix. The right move is A: keep Only Relevant Values only for the three controls that genuinely cascade, and simplify or remove the others. This directly eliminates the unnecessary re-query chain. Tableau no longer needs to refresh value lists for filters that have no meaningful dependency, so interaction time drops while the useful cascading behavior remains intact. The fix is targeted and proportional to the actual problem. B is tempting but flawed. Converting everything to context filters doesn't eliminate queries — it restructures them around a temporary table. You'd still be computing value lists for all 12 filters, and context filters carry their own overhead (rebuilding the temp table on each context change). This trades one performance problem for another. C misdiagnoses the issue. Switching to an extract improves raw query speed, but it leaves all 12 filter dependencies in place. You'd still trigger multiple value-list refresh queries on each interaction — they'd just run faster against local data. The cascade problem persists. D is a misconception about scope. Table calculations operate on data already returned by a query; they can't drive filter value lists, which are generated before the mark-level data is rendered. Study tip: On performance questions, distinguish between what triggers queries and how fast those queries run — the best fix usually reduces the number of queries, not just their speed.

Question 5

Users configure a dashboard by changing five independent filter controls in sequence. Each change causes all worksheets to refresh, but users do not need to inspect intermediate states while making their selections.

Which design choice best avoids repeated, unnecessary refresh work?

  1. Replace the filters with table-calculation filters so each intermediate state is hidden without recomputing the worksheets.
  2. Configure every filter to show only relevant values so Tableau can refresh each intermediate state with fewer selections.
  3. Add all five filters to context so the worksheets share one context that never changes during the selection sequence.
  4. Allow users to pause automatic updates, make the selections, and resume updates once the configuration is complete. (correct answer)
Explanation: When a question describes users making multiple sequential filter changes without needing to see intermediate results, you should immediately think about unnecessary query triggering. The core problem is that each filter change fires a fresh data query by default, so five changes generate five refreshes when only one final refresh is actually needed. Tableau's Pause Automatic Updates feature (the pause button in the toolbar) is designed exactly for this scenario. When users pause updates, they can adjust all five filters freely, then resume — triggering a single refresh that reflects the final configuration. This is why D is correct: it directly addresses the root problem by collapsing five refreshes into one. A is tempting but wrong. Table-calculation filters operate after data is returned from the source, meaning the underlying query still runs on every change. They reduce what's displayed, not what's computed. Using them doesn't prevent repeated refreshes. B confuses query efficiency with query frequency. "Only relevant values" (domain filtering) reduces the size of each refresh query, but a refresh still fires after every filter change. You've made each trip shorter, but you're still making five trips. C misapplies context filters. Adding filters to context is useful for optimizing filter processing order, but context itself gets recomputed when context filter values change. Making all five filters context filters would actually cause the context to rebuild with each sequential selection — potentially more expensive, not less. Study tip: On Tableau exam questions about performance and user interaction, watch for the phrase "does not need intermediate states" — it's a signal that Pause Automatic Updates is the intended tool.

Question 6

A worksheet contains several million customer-day marks and uses nested WINDOW_SUM and LOOKUP calculations. The published dashboard ultimately displays only monthly regional totals and month-over-month change.

Which redesign most directly addresses the principal table-calculation performance pitfall?

  1. Preaggregate the required data to month and region, then calculate the prior-period comparison on the smaller result. (correct answer)
  2. Add the customer identifier to Detail so Tableau can preserve every customer partition during the monthly comparison.
  3. Convert the date and region filters to context filters while retaining the customer-day marks and nested calculations.
  4. Display the calculations in tooltips rather than labels so Tableau evaluates them only when a user hovers.
Explanation: When you see a question about table-calculation performance, the core concept to focus on is partition size. Table calculations like WINDOW_SUM and LOOKUP operate row-by-row across the underlying query result set — not the visual summary. That means if your underlying data contains millions of marks, Tableau evaluates those calculations across millions of rows, even if the final view only shows a handful of aggregated values. Option A is the correct redesign because it attacks the root cause directly: too many marks entering the table-calculation engine. By preaggregating to month and region before the comparison logic runs, you reduce the partition from millions of customer-day rows to perhaps a few dozen monthly-regional subtotals. The nested WINDOW_SUM/LOOKUP then operates on that tiny result set, yielding dramatic performance gains without sacrificing any information the dashboard actually displays. Option B makes the problem worse, not better. Adding customer ID to Detail increases mark granularity, expanding the partition the table calculations must traverse. Option C is a common instinct — context filters do run earlier in Tableau's order of operations — but they still leave all the customer-day marks intact within the filtered scope; you've narrowed the data slightly but haven't collapsed it to the monthly grain the view needs. Option D is a misconception about how Tableau evaluates calculations. Moving a calculation to a tooltip defers its display, but Tableau still computes the underlying query result eagerly; you don't meaningfully avoid the performance cost. The study tip here: always ask "how many marks feed the table calculation?" Reducing mark count before the calculation runs is almost always more effective than changing filters or display locations.

Question 7

An analyst places a frequently changed Order Date range filter in context because a dependent Customer filter should show only customers with orders in the selected period. Each date adjustment is slow, while changing a noncontext Category filter is comparatively fast.

Which explanation and response best address this performance pattern?

  1. The context is rebuilt when the date changes; remove the date from context unless the dependent customer list justifies that recurring cost. (correct answer)
  2. The category filter is evaluated before context filters; move category into context so the date range is evaluated later.
  3. Context filters always scan the full data source; replace the date filter with a table-calculation filter to enable query pushdown.
  4. The customer domain is cached permanently after its first use; keep the design because subsequent date selections should require no queries.
Explanation: When you see a question about Tableau context filters and performance, think about the cost-benefit tradeoff: context filters rebuild a temporary table every time they change, so placing a high-frequency filter in context can be expensive. Here's what's happening in this scenario. Every time the analyst adjusts the date range, Tableau rebuilds the entire context — generating a new temporary table from the full data source. That rebuild is the source of the slowness. Answer A correctly identifies this: the context is reconstructed on each date change, and the analyst should evaluate whether the benefit (a correctly scoped Customer dependent filter) actually justifies paying that rebuild cost repeatedly. If the customer dependency is essential, the design is defensible; if not, the date filter should leave context. Answer B gets the filter order backwards. Context filters are evaluated first, before noncontext filters like Category — not after. Moving Category into context would only add more rebuild overhead, not delay the date evaluation. Answer C contains two misconceptions. Context filters don't "scan the full data source" in a way that table-calculation filters would bypass — and table-calculation filters actually run after aggregation in Tableau's order of operations, making them generally worse for performance, not better. Query pushdown doesn't apply here the way the answer implies. Answer D is simply false. The customer domain cache is not permanent across date selections. Changing the context filter (the date) invalidates and rebuilds that cache each time, which is precisely the performance problem being described. Your takeaway: on context-filter questions, always ask how often does this filter change? Frequent changes mean frequent rebuilds — context is best reserved for filters that are set once or rarely adjusted.

Question 8

A dashboard contains eight worksheets connected to the same data source. Each sheet applies the same three filters and performs a similar expensive table calculation. Users normally view only two of the worksheets, but all eight are included in the initial dashboard layout.

Which modification most directly reduces duplicated work during initial dashboard loading?

  1. Duplicate the data source for each worksheet so Tableau can process all eight views independently and potentially in parallel.
  2. Consolidate the three filter controls into one shared control so all worksheets reuse a single computed intermediate result.
  3. Remove or defer worksheets that users do not initially need, and consolidate sheets where one view can satisfy multiple requirements. (correct answer)
  4. Combine each sheet's table calculations into one calculated field so Tableau executes the shared logic only once across the dashboard.
Explanation: When optimizing dashboard load performance, think about what work Tableau actually needs to do at load time. Every worksheet rendered on initial load requires its own query, filter evaluation, and table calculation — so the number of active sheets directly multiplies the computational cost. The most impactful lever here is reducing the number of worksheets Tableau must render upfront. Since users only view two of the eight sheets initially, the other six are consuming query execution, filter processing, and expensive table calculations for no immediate benefit. Answer C targets this directly: removing or deferring unused sheets eliminates that wasted work entirely, and consolidating views means fewer redundant computations overall. Fewer sheets rendered = less duplicated effort at load time. Answer A makes things worse, not better. Duplicating the data source means Tableau maintains separate connections and caches, increasing overhead rather than sharing work across sheets. Parallelism doesn't eliminate redundancy — it just runs redundant work simultaneously. Answer B is a reasonable-sounding distractor, but filter controls are not the bottleneck described. Sharing a filter UI widget doesn't automatically make Tableau reuse a single intermediate computation for all eight sheets. Each sheet still executes its own query pipeline. Answer D misunderstands how table calculations work. Merging logic into one calculated field doesn't cause Tableau to share computation across separate worksheets — each sheet still evaluates its own result set independently. As a study tip: on Tableau performance questions, always trace the problem back to how many views are being rendered. Reducing rendered sheet count is almost always more impactful than optimizing what's inside those sheets.

Question 9

A live data source contains 100 million transaction rows. One worksheet's database query aggregates those rows to approximately 2,000 marks before Tableau evaluates a simple percent-of-total table calculation. The dashboard also exposes five high-cardinality filter controls.

Which conclusion is best supported by the information provided?

  1. Any table calculation over a 100-million-row source is necessarily the main bottleneck, even when the returned view has only 2,000 marks.
  2. The source row count alone does not prove the table calculation is the bottleneck; measure query, filter-domain, and local calculation costs separately. (correct answer)
  3. The five filter controls cannot affect performance because filter-domain queries use metadata rather than values from the data source.
  4. Replacing the live connection with an extract will necessarily remove both filter-domain work and percent-of-total computation.
Explanation: When troubleshooting Tableau dashboard performance, your first instinct should be to isolate where the slowness actually lives rather than assuming the most visible or largest component is the culprit. Performance has several distinct cost centers: the database query that aggregates raw rows into marks, filter-domain queries that populate dropdown lists, and local computations (like table calculations) that run in Tableau's engine after the query returns. B is correct because the scenario tells you the database query already reduces 100 million rows to ~2,000 marks before the percent-of-total table calculation ever runs. A table calculation operating on 2,000 marks is trivially fast. The real bottleneck could be the aggregation query itself, or the five high-cardinality filter controls each firing their own domain queries to populate their list of values. You cannot conclude the table calculation is slow without measuring each component separately — using tools like Tableau's built-in Performance Recorder. A is wrong because it fixates on the raw row count rather than what the table calculation actually receives. Row count in the source is irrelevant to a calculation that only sees 2,000 aggregated marks. C is wrong because filter-domain queries absolutely do hit the data source to retrieve distinct values — especially for high-cardinality fields. These queries can be a significant and often overlooked performance cost. D is wrong because an extract does not automatically eliminate either cost. Filter-domain queries still run against the extract, and percent-of-total is still computed locally regardless of connection type. Your study tip: on Tableau performance questions, always trace the data flow — source → query → marks → local calculation — and ask which stage is actually doing heavy work.

Question 10

Tableau Performance Recording shows that database queries complete in under one second. Most elapsed time is attributed to computing table calculations and rendering a worksheet containing hundreds of thousands of marks.

Which action is most likely to produce the largest improvement?

  1. Reduce the worksheet's mark count and simplify the calculations before considering a different connection type. (correct answer)
  2. Create an extract first because extracts eliminate the local processing required by table calculations and mark rendering.
  3. Add more visible filter controls because each control allows Tableau to cache a smaller subset of displayed marks.
  4. Make the existing calculations nested so Tableau can evaluate several table-calculation stages in a single database query.
Explanation: When Tableau Performance Recording reveals that database queries are fast but table calculations and mark rendering are slow, you've identified a client-side bottleneck — the problem lives in Tableau's local processing engine, not the database. Your fix should target exactly those two culprits directly. That's precisely what A does. Reducing the mark count (by filtering, aggregating, or redesigning the view) directly cuts rendering time, and simplifying table calculations reduces the computational load Tableau carries locally. Crucially, A also reflects good diagnostic discipline: address the confirmed bottlenecks before introducing architectural changes like switching connection types. B is tempting but contains a fundamental misconception. Extracts do speed up many queries by moving data to Tableau's fast in-memory engine, but they do not eliminate table calculation processing — Tableau still evaluates those calculations locally regardless of connection type. An extract won't solve the mark-rendering problem either. C misunderstands how filters and caching work. Adding more filter controls doesn't meaningfully improve performance through caching; it can actually increase complexity and query overhead. Fewer, well-designed filters are generally better for performance. D confuses table calculations with database queries. Table calculations are evaluated after data is returned from the database — they never execute as part of a SQL query. Nesting them doesn't push logic to the database; it only reorganizes client-side computation. As a study tip: always let the Performance Recording data guide your solution. If the recording points to a specific bottleneck, the best answer will target that bottleneck directly rather than introduce unrelated architectural changes.