mediumMultiple Choice
PDE Practice Question: After migrating a production Cloud SQL for…
After migrating a production Cloud SQL for PostgreSQL database to a larger machine type, the team notices slower queries. What is the best step to identify the cause?
⚠ Common exam trap
Google Cloud often tests the misconception that performance issues after a migration are always due to indexing or connection limits, when in fact the most effective first step is to gather query-level metrics using built-in tools like pg_stat_statements.
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
✓
Enable pg_stat_statements and review query execution times.
Pg_stat_statements is a PostgreSQL extension that provides detailed query execution statistics, including total execution time, number of calls, and I/O metrics. After migrating to a larger machine type, slower queries often stem from plan changes due to different hardware characteristics or configuration settings; reviewing pg_stat_statements output helps pinpoint which queries are underperforming and why.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Reindex all tables to improve index efficiency.
Why it's wrong here
Reindexing addresses index bloat or corruption, which a machine-type migration does not introduce, so it cannot identify the cause. It is the correct remedy when indexes have degraded through heavy update churn or when planner statistics and index health are the suspected bottleneck.
- ✗
Enable query caching through the database flags.
Why it's wrong here
Query caching masks repeated identical reads; it does not diagnose why execution slowed after the resize, and PostgreSQL's shared buffers already cache pages. Enabling it is correct when the same read-heavy statements recur and latency must drop, not when investigating a fresh performance regression.
- ✓
Enable pg_stat_statements and review query execution times.
Why this is correct
Enabling pg_stat_statements captures per-query execution statistics inside PostgreSQL itself, exposing which statements slowed after the resize. This satisfies the stem's need to identify the cause, since the extension aggregates total and mean execution times by normalised query, revealing plan regressions or resource contention that a machine-type change alone would not explain.
- ✗
Increase max_connections to handle more concurrent queries.
Why it's wrong here
Connection limits govern concurrency admission, not per-query execution speed, so raising max_connections cannot explain a regression appearing immediately after a machine-type change. It is the right lever when clients are queuing or refusing connections under load, which the stem does not describe.
Go deeper
Related to this question
About these practice questions
This PDE question is part of Courseiva's 747-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This PDE 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 PDE exam.