MIME-Version: 1.0
References: <CA+TgmoZ-Jh1T6QyWoCODMVQdhTUPYkaZjWztzP1En4=ZHoKPzw@mail.gmail.com>
 <CAKZiRmxtJAFG7e1+Vs9B8ngON=AOzJbuws+1ZeH4LsbJh5AzoQ@mail.gmail.com>
 <CA+TgmoY9Ne_Sh10u6LSPc3wvOQPLp3kF9nBp3nqJEG2JGF2QiA@mail.gmail.com>
 <CA+Tgmoa57S6mP=aTOXH2-gDAL4TMO1WbGgrHSg0s6J4zUH=04g@mail.gmail.com>
 <DEB1SAGVDX7S.JMV96X4R0RCS@gmail.com> <CA+Tgmoaf__2B0BUL+vrg28P+3buX=Ti-kybqkHiLTtFrrCfzuA@mail.gmail.com>
 <CA+TgmoYpcLNOuypOTdgCSLW7FuA=t6BtB3meTARHX2-Dj_81xQ@mail.gmail.com>
 <DEFNP3WX7BLX.1X7DS1P9X6JIF@nmfay.com> <CA+TgmoZjv9OyFu1Gkt78w0vWEti8S33w8trYHmErf-GMmGSi=w@mail.gmail.com>
 <DELPC4B56Y5A.3OBZ3WCH3T4VX@nmfay.com> <CA+TgmoaOSBQD9Ux4eG40w723ZN=c0J7p-+oX4+J8urUeyLMo5w@mail.gmail.com>
 <CAOYmi+=g+MMoOpWkk2weXWKJcKH0eKey8gKHHdH0dF4Tiawrhw@mail.gmail.com>
 <CA+TgmobwaT=PXPDDrgDup+jA8KHBbkxigtziD-zNzAKKkQYVgQ@mail.gmail.com>
 <CAOYmi+mOmEW=amDRQMfw6-Fb3ZmDEQFaJzwk8Bc8W8DzaP85XQ@mail.gmail.com>
 <CA+TgmoaX2AMW4cdFM3OngBJxmxpkdmzF33R7-CWhvRLfucbFMg@mail.gmail.com>
 <CAOYmi+k4AyWCQHK=XVF99KVDuFkqxcADao61OWGLxu0nRYMONQ@mail.gmail.com>
 <CA+TgmoZ0x3ym_oueXRWzbM_=6ucKoPZVGj3rRMLBDC_FnetXDw@mail.gmail.com>
 <CAP53Pkycc=7N2bLzVT3x+qE1JamvRZWev5tFjdLJ1+-AV3Di+Q@mail.gmail.com>
 <CA+TgmoaKhuD91RnazbRyGkmP7--JdNq8oNDC3UcgTZSWbMxC7w@mail.gmail.com>
 <CAP53Pkw5-wMEeDJXFmqo_RTyL_spzCXb7HHKrbSnQqokVoZcNQ@mail.gmail.com>
 <CA+Tgmob-69bzbdi3U_QtebqAf6u1y8js=5=oNK639csVe1VbhA@mail.gmail.com>
 <CA+TgmoaZMOikxK=LqS+Jn+835h9S139JLGk-3LyETVXw5W5j=w@mail.gmail.com>
 <1136161.1769654478@sss.pgh.pa.us> <CAP53PkwZ1ZTMARKg6iEfAw9qzBhkjBitj-9gr_Jvy7k2AwGgWA@mail.gmail.com>
 <CAMbWs4--NuEUFE_xTo991TRXaZryE29jarJPDnVxoaQOYdt7tA@mail.gmail.com> <CA+TgmobzR+XMGbRosVPbjHbSo4+cgJn=qZK6w05aF1sbj=C+9Q@mail.gmail.com>
In-Reply-To: <CA+TgmobzR+XMGbRosVPbjHbSo4+cgJn=qZK6w05aF1sbj=C+9Q@mail.gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
Date: Sat, 7 Feb 2026 11:44:39 -0500
Message-ID: <CA+TgmoawzvCoZAwFS85tE5+c8vBkqgcS8ZstQ_ohjXQ9wGT9sw@mail.gmail.com>
Subject: Re: pg_plan_advice
To: Richard Guo <guofenglinux@gmail.com>
Cc: Lukas Fittl <lukas@fittl.com>, Tom Lane <tgl@sss.pgh.pa.us>, 
	Jacob Champion <jacob.champion@enterprisedb.com>, Dian Fay <di@nmfay.com>, 
	Matheus Alcantara <matheusssilv97@gmail.com>, 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%2BTgmoawzvCoZAwFS85tE5%2Bc8vBkqgcS8ZstQ_ohjXQ9wGT9sw%40mail.gmail.com>
Precedence: bulk

On Thu, Jan 29, 2026 at 9:10=E2=80=AFAM Robert Haas <robertmhaas@gmail.com>=
 wrote:
> I think cost_material() got an enabled argument because of
> materialize_finished_plan(). Most of the time, plan nodes are created
> from paths, and we want to use the parent's pgs_mask to determine
> whether the chosen strategy (e.g. materialization) is enabled.
> However, materialize_finished_plan() creates a plan directly, so
> there's no RelOptInfo or JoinPathExtraData whose pgs_mask we can
> consult, and so we have to fall back on consulting enable_material
> directly. Once that parameter got added to cost_material(), it made
> sense to me to add it to create_material_path() as well.

If this explanation seems a little weak, it's because it was. Here's a
better explanation: the patch added a per-rel flag
PGS_NESTLOOP_MATERIALIZE that enables the use of a Nested Loop join
with an inner Materialize node. When we construct such a path, the
"parent" point for the materialize path points to the rel that is on
the inner side of the join, not the joinrel itself. But the pgs_mask
flags of the joinrel and its inner side could be different. Therefore,
the Materialize node can't just look at path->parent->pgs_mask to
decide whether to mark the node as disabled. So, when I wrote the
patch originally, I added an enabled flag here to make sure that we
pass down the information about whether the join method was enabled at
the joinrel level, since the joinrel's pgs_mask is not otherwise
available to cost_material(). Later on, I discovered the need for
PGS_CONSIDER_NONPARTIAL, but by then I had forgotten why that
"enabled" argument existed and pushed the logic to handle
PGS_CONSIDER_NONPARTIAL into cost_material(). So the logic as
currently committed is buggy in the case where the joinrel and the
innerrel have differing pgs_mask values. match_unsorted_outer() and
consider_parallel_nestloop() have the intention of generating
Materialize nodes only when materialization is enabled, so that the
Materialize nodes are never marked disabled. But with the patch as
committed, a non-partial Nested Loop with inner Materialize can
disable the Materialize node if the inner rel's pgs_mask has
PGS_CONSIDER_NONPARTIAL unset.

The right fix is to make all the decisions about whether the
Materialize nod should be created, and whether it should be enabled,
in the caller, and have none of that logic in cost_material(). I will
post a new patch set shortly, which will include a patch to rectify
this issue.

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