public inbox for [email protected]
help / color / mirror / Atom feedFrom: Robert Haas <[email protected]>
To: Richard Guo <[email protected]>
Cc: Lukas Fittl <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: Jacob Champion <[email protected]>
Cc: Dian Fay <[email protected]>
Cc: Matheus Alcantara <[email protected]>
Cc: Jakub Wartak <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: pg_plan_advice
Date: Sat, 7 Feb 2026 11:44:39 -0500
Message-ID: <CA+TgmoawzvCoZAwFS85tE5+c8vBkqgcS8ZstQ_ohjXQ9wGT9sw@mail.gmail.com> (raw)
In-Reply-To: <CA+TgmobzR+XMGbRosVPbjHbSo4+cgJn=qZK6w05aF1sbj=C+9Q@mail.gmail.com>
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>
<[email protected]>
<CA+Tgmoaf__2B0BUL+vrg28P+3buX=Ti-kybqkHiLTtFrrCfzuA@mail.gmail.com>
<CA+TgmoYpcLNOuypOTdgCSLW7FuA=t6BtB3meTARHX2-Dj_81xQ@mail.gmail.com>
<[email protected]>
<CA+TgmoZjv9OyFu1Gkt78w0vWEti8S33w8trYHmErf-GMmGSi=w@mail.gmail.com>
<[email protected]>
<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>
<[email protected]>
<CAP53PkwZ1ZTMARKg6iEfAw9qzBhkjBitj-9gr_Jvy7k2AwGgWA@mail.gmail.com>
<CAMbWs4--NuEUFE_xTo991TRXaZryE29jarJPDnVxoaQOYdt7tA@mail.gmail.com>
<CA+TgmobzR+XMGbRosVPbjHbSo4+cgJn=qZK6w05aF1sbj=C+9Q@mail.gmail.com>
On Thu, Jan 29, 2026 at 9:10 AM Robert Haas <[email protected]> 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.
--
Robert Haas
EDB: http://www.enterprisedb.com
view thread (143+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: pg_plan_advice
In-Reply-To: <CA+TgmoawzvCoZAwFS85tE5+c8vBkqgcS8ZstQ_ohjXQ9wGT9sw@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox