From: Tom Lane <tgl@sss.pgh.pa.us>
To: Zhang Mingli <zmlpostgres@gmail.com>
cc: exclusion@gmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18778: Query planning fails in ExecInitExprRec with
 unrecognized node type
In-reply-to: <dc467c76-e5e5-4eaf-950b-32097f32d4f2@Spark>
References: <18778-24cd399df6c806af@postgresql.org>
 <1919554.1737070534@sss.pgh.pa.us>
 <dc467c76-e5e5-4eaf-950b-32097f32d4f2@Spark>
Comments: In-reply-to Zhang Mingli <zmlpostgres@gmail.com>
	message dated "Sat, 18 Jan 2025 23:52:01 +0800"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2550568.1737219097.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Sat, 18 Jan 2025 11:51:37 -0500
Message-ID: <2550569.1737219097@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2550569.1737219097%40sss.pgh.pa.us>
Precedence: bulk

Zhang Mingli <zmlpostgres@gmail.com> writes:
> And I have a question that may not be directly related to the issue: why=
 is there a Subplan 2, and it appears to be unused?

Yeah, that's because the AlternativeSubPlan originally had two child
subplans: a parameterized one intended for a few calls, and a hashed
one to be used for a lot of calls.  We build both because at the time
when this needs to happen, we don't have any clue how many calls
there will be.  We wait till the very end of planning to decide which
one is more likely to win based on context, and then discard the
AlternativeSubPlan, replacing it with a direct reference to the chosen
SubPlan.  But the other one stays in the tree.  Getting rid of it
seemed complicated, and it won't be referenced at runtime so there's
not much penalty from leaving it there.  It is confusing, I admit.

			regards, tom lane