You are using Google BigQuery as your data warehouse. Your users report that the following simple query is running very slowly, no matter when they run the query: SELECT country, state, city FROM…

Question

Options

• AUsers are running too many concurrent queries in the system
• BThe [myproject:mydataset.mytable] table has too many partitions
• CEither the state or the city columns in the [myproject:mydataset.mytable] table have too many NULL values
• DMost rows in the [myproject:mydataset.mytable] table have the same value in the country column, causing data skew

• A
  14% (5)
• B
  9% (3)
• C
  3% (1)
• D
  74% (26)

Explanation

D is correct because GROUP BY country causes BigQuery to shuffle all rows sharing the same country value to a single worker slot - if most rows share one country (e.g., "USA"), that slot becomes a bottleneck while all others sit idle, producing consistently slow performance regardless of time of day.

A is wrong because too many concurrent queries would cause intermittent slowness that varies with system load - the question explicitly states the query is slow "no matter when they run it," ruling out a load-based cause.

B is wrong because excessive partitions would affect partition pruning during the scan phase, not the GROUP BY shuffle stage; you'd also typically see this only when queries lack partition filters, which this query doesn't use anyway.

C is wrong because NULLs in state or city don't influence performance here - those columns are only being read, not grouped on, and NULL values don't cause data skew in BigQuery's distributed shuffle.

Memory tip: Picture the GROUP BY as a sorting conveyor belt - data skew means one belt gets a mountain of packages while the rest are empty. Whenever a query is always slow and groups on a low-cardinality column (like country), think skew first.

No community discussion yet for this question.