Why COUNT(DISTINCT) Scans All Partitions Even with a Filter on the Partition Column
This PCDE practice question tests your understanding of define data structures and implement sql for business intelligence. The scenario asks you to isolate a root cause — eliminate options that address a different problem before choosing. A key principle to apply: partitioning. Once you have made your selection, read the full explanation to reinforce the concept and understand why each distractor is designed to mislead on exam day.
Exhibit
Refer to the exhibit.
-- Query that scans too many bytes
SELECT event_date, COUNT(DISTINCT user_id) as users
FROM `project.dataset.events`
WHERE event_date >= '2023-01-01'
GROUP BY event_date
-- INFORMATION_SCHEMA result for table `project.dataset.events`:
Size: 500 GB
Partitioned by: event_date (DATE)
Clustered by: user_id
Refer to the exhibit. The query scans 500 GB even though it filters on the partitioning column event_date and only needs data from 30 days. What is the most likely reason?
Clue words in this question
Noticing these words before you look at the options changes how you read each choice.
Clue: "most likely"
Why it matters: Probability qualifier — the question wants the most probable cause or outcome, not a guaranteed one. Eliminate low-probability options.
Exhibit
Refer to the exhibit.
-- Query that scans too many bytes
SELECT event_date, COUNT(DISTINCT user_id) as users
FROM `project.dataset.events`
WHERE event_date >= '2023-01-01'
GROUP BY event_date
-- INFORMATION_SCHEMA result for table `project.dataset.events`:
Size: 500 GB
Partitioned by: event_date (DATE)
Clustered by: user_id
A
COUNT(DISTINCT) often results in full table scan to ensure accuracy, even with partitions.
Why wrong: Incorrect. BigQuery's COUNT(DISTINCT) does support partition pruning when the filter is on the partition column, so it would not cause a full table scan in this scenario.
B
The query lacks a LIMIT clause.
Why wrong: Incorrect. Adding a LIMIT clause does not reduce the amount of data scanned; it only limits the output rows. BigQuery still scans all matching partitions.
C
The clustering on user_id is causing a full table scan.
Why wrong: Incorrect. Clustering on user_id affects the storage order within partitions but does not cause a full table scan. Partition pruning still applies based on the partition column.
D
The table is not actually partitioned by event_date; the filter is on a non-partitioned column.
Correct. If the table is not partitioned by event_date, the filter on event_date does not trigger partition pruning, resulting in a full scan of all 500 GB.
The answer is that COUNT(DISTINCT) forces a full scan of all partitions, even with a filter on the partition column. This happens because the SQL engine must verify global uniqueness across the entire dataset—it cannot assume that distinct values are confined to the filtered partitions without scanning every partition, which disables partition pruning. On the Google Professional Cloud Database Engineer exam, this is a classic trap: candidates often expect a filter on the partition key to reduce the scan, but COUNT(DISTINCT) overrides that optimization to guarantee accuracy, especially in engines like BigQuery. The key insight is that distinct aggregation requires a complete view of all data to avoid missing values that might cross partition boundaries. Memory tip: “Distinct demands the whole dataset—partition pruning is paused for precision.”
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
The table is not actually partitioned by event_date; the filter is on a non-partitioned column.
The query filters on event_date and expects partition pruning, but if the table is not partitioned by event_date, BigQuery cannot skip irrelevant partitions. This would cause a full table scan of 500 GB regardless of the filter. In BigQuery, partition pruning works for most aggregation functions including COUNT(DISTINCT) when the filter is on the partition column, so option A is incorrect. Therefore, the most likely reason is that the partitioning column is not event_date.
Key principle: Partitioning
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
✗
COUNT(DISTINCT) often results in full table scan to ensure accuracy, even with partitions.
Why it's wrong here
Incorrect. BigQuery's COUNT(DISTINCT) does support partition pruning when the filter is on the partition column, so it would not cause a full table scan in this scenario.
✗
The query lacks a LIMIT clause.
Why it's wrong here
Incorrect. Adding a LIMIT clause does not reduce the amount of data scanned; it only limits the output rows. BigQuery still scans all matching partitions.
✗
The clustering on user_id is causing a full table scan.
Why it's wrong here
Incorrect. Clustering on user_id affects the storage order within partitions but does not cause a full table scan. Partition pruning still applies based on the partition column.
✓
The table is not actually partitioned by event_date; the filter is on a non-partitioned column.
Why this is correct
Correct. If the table is not partitioned by event_date, the filter on event_date does not trigger partition pruning, resulting in a full scan of all 500 GB.
Clue confirmation
The clue word "most likely" in the question point toward this answer.
Related concept
Partitioning
Common exam traps
Common exam trap: answer the scenario, not the keyword
A common trap is assuming that a filter on a date column implies partition pruning, but if the table is not partitioned by that column, the filter has no effect on the scanned data. BigQuery supports partition pruning for COUNT(DISTINCT) when the partition column is used in the filter.
Trap categories for this question
Command / output trap
Incorrect. Adding a LIMIT clause does not reduce the amount of data scanned; it only limits the output rows. BigQuery still scans all matching partitions.
Scenario analysis trap
Incorrect. BigQuery's COUNT(DISTINCT) does support partition pruning when the filter is on the partition column, so it would not cause a full table scan in this scenario.
Detailed technical explanation
How to think about this question
Under the hood, COUNT(DISTINCT) often requires a hyperloglog or similar sketch algorithm to estimate distinct counts, but for exact counts, the engine must shuffle and deduplicate across all partitions. In systems like BigQuery, partition pruning is disabled for COUNT(DISTINCT) over a partitioned column because the distinct values could exist in any partition, leading to a full scan. A real-world scenario is when querying daily user logins over 30 days but needing exact unique users; the engine scans all partitions to ensure no user from outside the date range is missed.
KKey Concepts to Remember
Partitioning
Partition Pruning
TExam Day Tips
→Watch for words such as best, first, most likely and least administrative effort.
→Review why wrong options are wrong, not only why the correct option is correct.
Key takeaway
Partitioning
Real-world example
How this comes up in practice
A cloud solutions architect for a retail company is evaluating services for a new workload. The correct answer here reflects best practice for the specific scenario described — not a general cloud recommendation. Partitioning Cloud exam questions reward reading the constraint carefully: the same technology can be right or wrong depending on the use case.
What to study next
Got this wrong? Here's your next step.
Review partitioning, then practise related PCDE questions on the same topic to reinforce the concept.
Define data structures and implement SQL for Business Intelligence — This question tests Define data structures and implement SQL for Business Intelligence — Partitioning.
What is the correct answer to this question?
The correct answer is: The table is not actually partitioned by event_date; the filter is on a non-partitioned column. — The query filters on event_date and expects partition pruning, but if the table is not partitioned by event_date, BigQuery cannot skip irrelevant partitions. This would cause a full table scan of 500 GB regardless of the filter. In BigQuery, partition pruning works for most aggregation functions including COUNT(DISTINCT) when the filter is on the partition column, so option A is incorrect. Therefore, the most likely reason is that the partitioning column is not event_date.
What should I do if I get this PCDE question wrong?
Review partitioning, then practise related PCDE questions on the same topic to reinforce the concept.
Are there clue words in this question I should notice?
Yes — watch for: "most likely". Probability qualifier — the question wants the most probable cause or outcome, not a guaranteed one. Eliminate low-probability options.
What is the key concept behind this question?
Partitioning
About these practice questions
Courseiva creates original exam-style practice questions with explanations and wrong-answer analysis. It does not publish real exam questions, exam dumps, or protected exam content. Learn why practice questions differ from exam dumps →
Share a tip, memory trick, or ask about the reasoning behind this question. Do not post real exam questions, leaked content, braindumps, or copyrighted exam material. Comments are moderated and may be removed without notice.
This PCDE practice question is part of Courseiva's free Google Cloud certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the PCDE exam.
Question Discussion
Share a tip, memory trick, or ask about the reasoning behind this question. Do not post real exam questions, leaked content, braindumps, or copyrighted exam material. Comments are moderated and may be removed without notice.
Sign in to join the discussion.