---
conversation_id: "68a2f0c1-3dc4-4e19-9d42-7f5b1c9e2a10"
source: chatgpt
title: "Postgres query plan"
created: "2026-07-13T09:14:03Z"
updated: "2026-07-13T09:31:47Z"
synced: "2026-07-13T09:32:02Z"
url: "https://chatgpt.com/c/68a2f0c1-3dc4-4e19-9d42-7f5b1c9e2a10"
---

**Human**

Why did our Postgres query plan change after the upgrade?

**Assistant**

The planner now prefers a parallel sequential scan — the upgrade changed the default cost model, so the old index path no longer wins. Three ways to confirm it:

1. Run `EXPLAIN (ANALYZE, BUFFERS)` on the query and compare the estimated vs. actual row counts.
2. Check `SHOW parallel_setup_cost;` and `SHOW parallel_tuple_cost;` against your pre-upgrade configuration.
3. Temporarily `SET enable_seqscan = off;` in a session and re-run the plan — if the index path returns and is faster, the cost model is the culprit.

If the index plan wins, raise the parallel costs (or lower `random_page_cost` for SSD-backed storage) rather than disabling sequential scans globally.