pg_plan_filter 1.0 can stop a query before it runs

PGX Inc. also released pg_plan_filter 1.0.0 on 7 October 2026. It is a loadable PostgreSQL module that inspects a statement against rules you configure and raises an error before the statement runs. The first rules are about planner cost. It works on PostgreSQL 14 through 18.

Three settings cover the initial idea. statement_cost_limit refuses one statement whose plan looks too expensive. transaction_cost_limit caps the combined cost of every statement in a transaction. filter_select_only can limit the check to SELECT, so writes you have already decided to allow are not caught by a read-oriented guard. The authors say the module can grow more kinds of filters later. Cost is the one that exists now.

This is a guardrail, not a query tuner. The planner’s cost is an estimate. A statement under the limit can still be slow, and a statement over the limit might have been fine on the real data. What the module does well is stop the obvious accident: an unbounded join, a report someone pasted into production, a transaction that keeps adding cheap-looking statements until the sum is not cheap. The error happens before execution, which is earlier than a statement_timeout that kills the query after it has already started doing damage.

Administrators should treat the numbers as policy. Set them from the costs of queries you are willing to run, not from a default copied out of a blog. Start in a staging database where a rejected statement is a log line, not a failed checkout. And remember that a filter on estimates can be bypassed by a plan that looks cheap and is not.

For a production primary that more than one team can query, a hard stop at plan time is still a useful new lever. PostgreSQL did not have this one built in. pg_plan_filter 1.0 is a small module that adds it.