PostgreSQL administrators now have a new tool for guarding production databases against expensive queries. pg_plan_filter version 1.0.0 has been released as a loadable module that tests statements against configured criteria before execution, raising an error when those criteria are violated. Filtering happens against the planner's estimated cost, so a query can be rejected before it ever touches the data.
The module's behaviour is governed by a small set of settings:
statement_cost_limitrefuses an individual statement whose estimated plan cost exceeds the configured threshold.transaction_cost_limitcaps the combined cost of all statements executed within a single transaction, preventing a series of individually acceptable queries from adding up to a runaway workload.filter_select_onlyoptionally restricts enforcement toSELECTstatements, leaving writes and other commands unaffected.- Compatibility spans PostgreSQL versions 14 through 18, and the design is explicitly intended to be extended with further kinds of filters.
Because the check is based on planner estimates, the module is a policy layer rather than a resource governor. It cannot predict execution-time surprises such as bad row estimates or lock waits, but it eliminates an entire class of accidental heavy queries at the door. For teams running multi-tenant platforms, shared clusters, or ad-hoc analyst access, that means cost limits can be enforced centrally instead of relying on application-side query review.
Being a loadable module, it requires no core patches, so it can be rolled out with existing upgrade and configuration management. Developers should treat rejected statements as actionable feedback: a raised error signals that a query needs rewriting, better indexing, or a higher limit granted deliberately. Reviewing EXPLAIN output for those statements is the natural next step, and the configurable boundaries make it practical to tune limits per environment rather than applying one global ceiling. The project notes that additional filter types are possible, so more granular controls may follow.
Source: https://www.postgresql.org/about/news/pg_plan_filter-100-released-3352/