# Plan Advice in PostgreSQL 19

DevFeed: [Plan Advice in PostgreSQL 19](<https://devfeed.tech/articles/plan-advice-in-postgresql-19-34622.md>)

Original publisher: [Read original article](<https://tapoueh.org/blog/2026/09/plan-advice-in-postgresql-19/>)

Author: Dimitri Fontaine PostgreSQL Major Contributor; Author

Published: 2026-09-15T16:27:53Z

Content type: tutorial

Language: en

Sources: [Dimitri Fontaine](<https://devfeed.tech/sources/dimitri-fontaine.md>)

Topics: [PostgreSQL](<https://devfeed.tech/topics/postgresql.md>), [version](<https://devfeed.tech/topics/version.md>), [SQL](<https://devfeed.tech/topics/sql.md>), [Docker Compose](<https://devfeed.tech/topics/docker-compose.md>)

Tags: [analyze](<https://devfeed.tech/tags/analyze.md>), [beta](<https://devfeed.tech/tags/beta.md>), [docker-compose](<https://devfeed.tech/tags/docker-compose.md>), [pg-plan-advice](<https://devfeed.tech/tags/pg-plan-advice.md>), [postgresql](<https://devfeed.tech/tags/postgresql.md>), [sql](<https://devfeed.tech/tags/sql.md>)

## AI overview

This tutorial explains PostgreSQL 19's pg_plan_advice and pg_stash_advice modules, which represent query-plan decisions as reusable advice and can apply that advice by query ID. It also describes reconstructing comparable plan advice from ordinary plan output on earlier PostgreSQL versions.

## Source excerpt

There is a conversation that happens in every PostgreSQL shop eventually. A query that has been fine for a year gets slow overnight. Nothing was deployed. The data grew a little, ANALYZE ran, and the planner -- entirely reasonably, on the numbers it had -- picked a different plan. The old plan was better. You would like it back. PostgreSQL 19 ships two new modules for exactly this: pg_plan_advice, which can read a plan back out as a string and enforce it later, and pg_stash_advice, which keeps those strings keyed by query id and applies them automatically. ▸ Every query below ran against the Lab, the free dataset bundle used throughout this blog, on PostgreSQL 19 Beta 3: POSTGRES_VERSION=19beta3 PG_MAJOR=19 docker compose up. Both modules are contrib, and the Lab image ships them; nothing below runs a LOAD to enable them, because the server already has them -- pg_plan_advice in session_preload_libraries, pg_stash_advice in shared_preload_libraries (it can survive a restart, which needs loading that way). One line each in postgresql.conf, or the equivalent server-start flag, and you're done. pg_stash_advice still needs its own CREATE EXTENSION, further down, for its SQL functions -- that's independent of how the module itself got loaded.