PostgreSQL Updates Crawling? Here’s What’s Happening
A reader comment on our recent performance post raises a valid pain point: PostgreSQL updates on large tables can slow to a crawl even when you’re not repeatedly updating the same row. On PostgreSQL 14, updating a big table joined on a primary key proved “prohibitively slow” for the commenter, who now recommends a blunt workaround: create a fresh table and drop the old one instead of running the update in place.
That workaround isn’t cheap either. The commenter, a C programmer, says they routinely deal with tables around 10 million rows, and an update can take three or more hours—all while the database appears idle, with CPU, disk, and update activity flatlining in pgAdmin.
The core request: a “real” update that doesn’t secretly perform new inserts under the hood. The author acknowledges there may be consequences to less defensive update handling, but argues the current behavior is over-protective of poorly conceived queries and forces users to suffer needless downtime.
The takeaway? If you’re seeing glacial update times on large, primary-key-joined tables in PG14, you’re not alone—and the standard advice about repeated updates may not apply to your case. Sometimes the pragmatic fix is to rebuild the table, even if it feels wasteful.
