Re: Get rid of runtime handling of AlternativeSubPlan? - Mailing list pgsql-hackers

From David Rowley
Subject Re: Get rid of runtime handling of AlternativeSubPlan?
Date
Msg-id CAApHDvqhcEab0aJ29C+yznHiUHNqoKvTOL+sz0p3a1SNon4ntg@mail.gmail.com
Whole thread Raw
In response to Re: Get rid of runtime handling of AlternativeSubPlan?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Get rid of runtime handling of AlternativeSubPlan?
List pgsql-hackers
On Sun, 30 Aug 2020 at 11:26, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> I wrote:
> > Therefore, I'm considering the idea of ripping out all executor support
> > for AlternativeSubPlan and instead having the planner replace an
> > AlternativeSubPlan with the desired specific SubPlan somewhere late in
> > planning, possibly setrefs.c.
>
> Here's a proposed patchset for that.

Do you feel that the choice to create_plan() on the subplan before
planning the outer query is still a good one?  ISTM that that was
required when the AlternativeSubplan decision was made during
execution, since we, of course, need a plan to execute. If the
decision is now being made in the planner then is it not better to
delay the create_plan() until later in planning?

From looking at the code it seems that Paths won't really do here as
we're dealing with two separate PlannerInfos rather than two paths
belonging to the same PlannerInfo, but maybe it's better to invent
something else that's similar to a list of paths and just do
create_plan() for the subquery once.

David



pgsql-hackers by date:

Previous
From: Tatsuro Yamada
Date:
Subject: Re: list of extended statistics on psql
Next
From: Li Japin
Date:
Subject: Re: Terminate the idle sessions