MIME-Version: 1.0
References: 
 <CA+TgmoZ-Jh1T6QyWoCODMVQdhTUPYkaZjWztzP1En4=ZHoKPzw@mail.gmail.com>
 <CAKZiRmxtJAFG7e1+Vs9B8ngON=AOzJbuws+1ZeH4LsbJh5AzoQ@mail.gmail.com>
 <CA+TgmoZf1F360z6jNVZyv7UF=URSNvCWbsCX7A_nsH=iaEqm0A@mail.gmail.com>
 <CAC0GmywDf5cs1_DoCyZwec=73Q5P7t88ikJ=LuKLXPO-Fd2LFQ@mail.gmail.com>
In-Reply-To: 
 <CAC0GmywDf5cs1_DoCyZwec=73Q5P7t88ikJ=LuKLXPO-Fd2LFQ@mail.gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
Date: Mon, 3 Nov 2025 11:18:08 -0500
Message-ID: 
 <CA+TgmoZcrvSB_5d_H1WT2UiZMuRiG+OF1LTyKZ0JK5Gaz3k1hw@mail.gmail.com>
Subject: Re: pg_plan_advice
To: Alastair Turner <minion@decodable.me>
Cc: Jakub Wartak <jakub.wartak@enterprisedb.com>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CA%2BTgmoZcrvSB_5d_H1WT2UiZMuRiG%2BOF1LTyKZ0JK5Gaz3k1hw%40mail.gmail.com>
Precedence: bulk

On Fri, Oct 31, 2025 at 5:17=E2=80=AFPM Alastair Turner <minion@decodable.m=
e> wrote:
> I really like the functionality of the current patch as well, even though=
 I am suspicious of user control over the planner. By giving concise, preci=
se control over a plan, this allows people who believe they can out-plan th=
e planner to test their alternative, and possibly fail.

Indeed. The downside of letting people control anything is that they
may leverage that control to do something bad. However, I think it is
unlikely that very many people would prefer to write an entire query
plan by hand. If you wanted to do that, why would you being using
PostgreSQL in the first place? Furthermore, if somebody does try to do
that, I expect that they will find it frustrating and difficult: the
planner considers a large number of options even for simple queries
and an absolutely vast number of options for more difficult queries,
and a human being trying possibilities one by one is only ever going
to consider a tiny fraction of those possibilities. The ideal
possibility often won't be in that small subset of the search space,
and the user will be wasting their time. If that were the design goal
of this feature, I don't think it would be worth having.

But it isn't. As I say in the README, what I consider the principal
use case is reproducing plans that you know to have worked well in the
past. Sometimes, the planner is correct for a while and then it's
wrong later. We don't need to accept the proposition that users can
out-plan the planner. We only need to accept that they can tell good
plans from bad plans better than the planner. That is a low bar to
clear. The planner never finds out what happens when the plans that it
generates are actually executed, but users do. If they are
sufficiently experienced, they can make reasonable judgements about
whether the plan they're currently getting is one they'd like to
continue getting. Of course, they may make wrong judgements even then,
because they lack knowledge or experience or just make a mistake, but
it's not a farcically unreasonable thing to do. I've basically never
wanted to write my own query plan from scratch, but I've certainly
looked at many plans over the years and judged them to be great, or
terrible, or good for now but risky in the long-term; and I'm probably
not the only human being on the planet capable of making such
judgements with some degree of competence.

> Whatever other UIs and integrations you build as you develop this towards=
 you goal, please keep what's currently there user accessible. Not only for=
 testing code, but also for testing users' belief that they know better.

And this is also a good point. Knowledgeable and experienced users can
look at a plan that the planner generated, feel like it's bad, and
wonder why the planner picked it. You can try to figure that out by,
for example, setting enable_SOMETHING =3D false and re-running EXPLAIN,
but since there aren't that many such knobs relevant to any given
query, and since changing any of those knobs can affect large swathes
of the query and not just the part you're trying to understand better,
it can actually be really difficult to understand why the planner
thought that something was the best option. Sometimes you can't even
tell whether the planner thinks that the plan you expected to be
chosen is *impossible* or just *more expensive*, which is always one
of the things that I'm keen to find out when something weird is
happening. This can make answering that question a great deal easier.
If some important index is not getting used, you can say "no, really,
I want to see what happens with this query when you plan it with that
index" -- and then it either gives you a plan that does use that
index, and you can see how much more expensive it is and why, or it
still doesn't give you a plan using that index, and you know that the
index is inapplicable to the query or unusable in general for some
reason. You don't necessarily have it as a goal to coerce the planner
in production; your goal may very well be to find out why your belief
that you know better is incorrect.

--=20
Robert Haas
EDB: http://www.enterprisedb.com