# planner Published articles for planner. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Waiting for PostgreSQL 19 - Add pg\_plan\_advice contrib module. DevFeed: [Waiting for PostgreSQL 19 - Add pg\_plan\_advice contrib module.]() Original publisher: [Read original article]() Author: depesz Published: 2026-03-22T13:44:10Z Content type: tutorial Language: en Sources: [select \* from depesz;]() Topics: [PostgreSQL](), [systems]() Tags: [advice](), [hint](), [module](), [pg-plan-advice](), [pg19](), [plan](), [planner](), [postgresql](), [statistics](), [uncategorized](), [waiting]() ### AI overview This article examines PostgreSQL's proposed pg_plan_advice contrib module, explaining why query planners sometimes choose suboptimal plans, how plan hints could stabilize or override those choices, and how to load and test the extension. ### Source excerpt On 12nd of March 2026, Robert Haas committed patch: Add pg_plan_advice contrib module. Provide a facility that (1) can be used to stabilize certain plan choices so that the planner cannot reverse course without authorization and (2) can be used by knowledgeable users to insist on plan choices contrary to what the planner believes ... Continue reading "Waiting for PostgreSQL 19 - Add pg_plan_advice contrib module." ## Waiting for PostgreSQL 19 - Introduce the REPACK command DevFeed: [Waiting for PostgreSQL 19 - Introduce the REPACK command]() Original publisher: [Read original article]() Author: depesz Published: 2026-03-19T18:07:59Z Content type: article Language: en Sources: [select \* from depesz;]() Topics: [PostgreSQL](), [postgresql clusters]() Tags: [analyze](), [bloat](), [command](), [indexes](), [locking](), [maintenance](), [pg-repack](), [pg19](), [planner](), [postgresql](), [repack](), [uncategorized](), [vacuum](), [waiting]() ### AI overview The article examines PostgreSQL 19's proposed built-in REPACK command, which combines functionality associated with VACUUM FULL and CLUSTER. It demonstrates reclaiming space and reordering a table, discusses locking because concurrent operation is not yet supported, and introduces the pg_stat_progress_repack progress view and available command forms. ### Source excerpt On 10th of March 2026, Álvaro Herrera committed patch: Introduce the REPACK command REPACK absorbs the functionality of VACUUM FULL and CLUSTER in a single command. Because this functionality is completely different from regular VACUUM, having it separate from VACUUM makes it easier for users to understand; as for CLUSTER, the term is heavily ... Continue reading "Waiting for PostgreSQL 19 - Introduce the REPACK command" ## SQLite Query Optimisation - How the Planner Thinks and Where It Goes Wrong DevFeed: [SQLite Query Optimisation - How the Planner Thinks and Where It Goes Wrong]() Original publisher: [Read original article]() Published: 2026-03-08T00:00:00Z Content type: tutorial Language: en Sources: [Gaurav Sarma's Blog]() Topics: [SQLite](), [SQL](), [Databases]() Tags: [b-tree](), [index](), [optimisation](), [planner](), [query](), [query-planner](), [sql](), [sqlite]() ### AI overview A tutorial on how SQLite's query planner chooses between index searches and full table scans. It explains planner behavior, the effects of query patterns and data distribution, and how to avoid conditions that make indexes inaccessible or scans appear cheaper. ### Source excerpt . [SQLite Query Optimisation](sqlite-query-optimisation-cover... ## pg\_plan\_advice: Plan Stability and User Planner Control for PostgreSQL? DevFeed: [pg\_plan\_advice: Plan Stability and User Planner Control for PostgreSQL?]() Original publisher: [Read original article]() Author: Robert Haas (noreply@blogger.com) Published: 2026-03-04T17:55:00Z Content type: opinion Language: en Sources: [Robert Haas]() Topics: [PostgreSQL](), [JOIN](), [modules](), [Query (disambiguation)]() Tags: [join](), [modules](), [plan](), [planner](), [postgresql](), [query](), [test]() ### AI overview The article presents a proposed PostgreSQL 19 patch set introducing the pg_plan_advice, pg_collect_advice, and pg_stash_advice contrib modules. It demonstrates how pg_plan_advice can generate plan advice strings, preserve selected planner decisions, or vary advice to produce a different join plan. ### Source excerpt I'm proposing a very ambitious patch set for PostgreSQL 19. Only time will tell whether it ends up in the release, but I can't resist using this space to give you a short demonstration of what it can do. The patch set introduces three new contrib modules, currently called pg_plan_advice, pg_collect_advice, and pg_stash_advice. Read more " ## Nordic PostgreSQL Day 2015 DevFeed: [Nordic PostgreSQL Day 2015]() Original publisher: [Read original article]() Published: 2015-03-16T14:50:00Z Content type: article Language: en Sources: [Dimitri Fontaine]() Topics: [PostgreSQL](), [SQL](), [Open Source]() Tags: [developers](), [internals](), [jsonb](), [learn](), [open-source](), [planner](), [postgresql](), [sql](), [window-functions]() ### AI overview Nordic PostgreSQL Day 2015 is presented as a conference opportunity for developers and PostgreSQL users. The featured PostgreSQL for Developers talk covers solving a use case in SQL, SQL window functions, ranges, JSONB capabilities, and query planner internals. ### Source excerpt The PostgreSQL for Developers talk begins with a simple use case for developers to solve entirely in SQL. Discover SQL window functions if you don't know them already, and then see about advanced PostgreSQL stuff such as ranges. ## Finding plans in pg\_stat\_plans easily with pg\_find\_plans DevFeed: [Finding plans in pg\_stat\_plans easily with pg\_find\_plans]() Original publisher: [Read original article]() Author: Peter Geoghegan (noreply@blogger.com) Published: 2012-12-04T10:40:00Z Content type: article Language: en Sources: [Peter Geoghegan's blog]() Topics: [PostgreSQL](), [Databases](), [SQL](), [JSON](), [Python](), [Monitoring]() Tags: [join](), [json](), [pg-stat-plans](), [pg-stat-statements](), [planner](), [postgresql](), [python](), [sql]() ### AI overview The article introduces pg_find_plans, an experimental pg_stat_plans submodule for PostgreSQL. It uses machine-readable EXPLAIN output to search stored execution plans by criteria such as sequential scans, execution costs, and join counts directly from SQL. The article also discusses its PL/Python and PL/pgSQL implementation, input sanitization, limitations, and the usefulness of JSON for representing plan structures. ### Source excerpt As I recently blogged about, pg_stat_plans is a PostgreSQL satellite project I've been working on that aims to support earlier versions of Postgres that cannot use the new pg_stat_statements, and to track execution costs at the plan rather than the query granularity. It allows the user to easily explain each stored query text to see the plan for the entry, and has features that facilitate monitoring planner regressions. Since PostgreSQL 9.0, support for machine-readable EXPLAIN output has existed. I'm not aware that anyone else got around to actually doing something interesting with this capability, though. I knew that in order to get the most benefit from pg_stat_plans, it ought to be possible to leverage this capability to search for plans based on arbitrary criteria, directly from SQL. I've written an experimental submodule of pg_stat_plans, called pg_find_plans, that is designed to do just that - to quickly find plans and their execution costs, for those plans that, say, perform a sequential scan on a known large table. Here's the description of pg_find_plans from its documentation: pg_find_plans is written in PL/Python and PL/PgSQL. It is intended to provide users with a better way to ask questions like "what are the execution costs of all plans tracked since last statistics reset that involve a sequential scan against mytable, and have more than 2 joins?". That might be written as: mydb=# select join_count(json_plan), p.* from pg_stat_plans p join stored_plans sp on (p.userid=sp.userid and p.dbid=sp.dbid and p.planid=sp.planid) where from_our_database and join_count(json_plan) > 2 and contains_node(json_plan, 'Seq Scan', 'mytable'); order by 1 desc nulls last; Users should have a high degree of confidence that their queries on plan's structure are free of detectable errors, and pg_find_plans ensures this by carefully sanitising user input. For example, if the node of interest was specified as 'seq scan' above, the query would raise an error - to do any less mi ## First release of pg\_stat\_plans DevFeed: [First release of pg\_stat\_plans]() Original publisher: [Read original article]() Author: Peter Geoghegan (noreply@blogger.com) Published: 2012-10-20T14:53:00Z Content type: release Language: en Sources: [Peter Geoghegan's blog]() Topics: [PostgreSQL](), [Databases](), [SQL](), [Open Source](), [Logging]() Tags: [database](), [open-source](), [performance](), [pg-stat-plans](), [pg-stat-statements](), [planner](), [postgresql](), [query](), [release](), [sql]() ### AI overview The article announces the first release of pg_stat_plans, an open-source PostgreSQL module based on pg_stat_statements. It analyzes plan execution costs and planner regressions, extends normalized-statement analysis to PostgreSQL 9.0 and 9.1, and tracks plan costs over time. ### Source excerpt Anyone who attended my recent talk at Postgres Open, which was co-presented with my 2ndQuadrant colleague Greg Smith, "Beyond Query Logging", will be aware that pg_stat_statements, the standard contrib module that assigns execution costs to queries and makes them available from a view in the database, has been improved considerably in the recent 9.2 Postgres release. It has been improved in a way that we believe will alter the preferred approach to workload analysis on PostgreSQL databases away from log analysis tools, which just don't offer the performance, flexibility or granularity of this new approach. We also announced a new open source tool that addresses a related but slightly different problem (the analysis of plan execution costs, and planner regressions), as well as making most of the benefits of pg_stat_statements on 9.2 available to users stuck on earlier versions of Postgres. This new tool is called pg_stat_plans, and is itself based on pg_stat_statements. The 9.2 pg_stat_statements feature of particular importance, the ability to "normalise" non-prepared statements that the large majority of applications use exclusively is now brought to earlier versions (versions 9.0 and 9.1, though pg_stat_plans works fine on 9.2 too). Since pg_stat_plans fingerprints plans rather than query trees, the way this works is slightly different to pg_stat_statements, and perhaps doesn't quite match people's intuitive expectations about how normalisation ought to behave in some cases. These differences have been extensively documented. pg_stat_plans also has the ability to EXPLAIN a stored, representative SQL text, in order to facilitate deeper analysis of plan execution costs. Plan total_cost and startup_cost is tracked over time for each plan, for example, so that the "crossover point" at which the planner begins to prefer an alternative plan can sometimes be observed, and the planner's "reasoning" can perhaps be better understood. pg_stat_plans is distributed under the P