News and analysis
Heavy queries: plan estimates and large database values
pg_plan_filter limits estimated plans; PlanetScale examines TOAST. Separate pre-execution checks from measurements of the actual report.
A report selects a few thousand rows, each containing a large text or JSON value. The record count seems modest, but reading still delays work. Two October publications help separate advance query estimation from the behaviour of stored data during execution.
The guard uses a planner estimate
On 7 October, the PostgreSQL community site published pg_plan_filter 1.0.0. The module checks estimated plan cost before execution, supports statement and transaction limits, and can apply only to SELECT. Its stated compatibility is PostgreSQL 14–18.
This is not a millisecond timeout or a guarantee of actual resource consumption. An owner needs to understand the boundary: reject a plan exceeding an agreed estimated-cost limit. Behaviour of an executing query and acceptable user waiting time need separate checks.
The design should explain refusal to the employee. If a report cannot start because of a limit, the team needs a reason and an allowed next action. Repeating the same query indefinitely is not workflow recovery.
Large values have their own storage path
On 12 October, PlanetScale examined TOAST in Postgres, where large variable-length values can be compressed or stored outside the main row. Actual behaviour depends on data and configuration; the article’s numeric example does not establish the same threshold for every record.
It also distinguishes version configurations. Do not automatically transfer capabilities discussed for PostgreSQL 19 beta to a module declaring support for 14–18. Check the actual version and settings before choosing an approach.
Bring the plan and result into one assessment
The substantive connection is that pre-execution estimates and the cost of reading large values describe different parts of the same task. A plan filter does not replace measurement; convenient text storage does not make a report lightweight by default.
Choose a representative query and anonymized data with varied field sizes. Compare reading required columns with retrieving full content. Record the plan, actual duration, result size and correctness. Do not change production storage based on one synthetic example.
Then test rejection at the configured boundary and the employee’s next action. The report may need a narrower period, fewer fields or a separate execution environment. Those are options to assess for the project rather than universal configuration instructions. Keep the acceptance criteria with the evidence so a later change can be checked on comparable conditions.
Our spreadsheet-to-system guide helps establish reporting data. The historical mailing analytics case supplies integration context without a modern speedup promise. For your data-processing workflow, discuss the query, large fields and result criteria.