I wrote: > Nope. The entire reason why we have that kluge is that we don't know > until much later how many times we expect to execute the subplan. > AlternativeSubPlan allows the decision which subplan form to use to be > postponed till runtime; but when we're doing things like estimating the > cost and selectivity of a where-clause, we don't know that.
> Maybe there's some way to recast things to avoid that problem, > but I have little clue what it'd look like.
Actually ... maybe it's not that bad. Clearly there would be a circularity issue for selectivity estimation, but all the alternatives should have the same selectivity. Cost estimation is a different story: by the time we need to do cost estimation for a subexpression, we do in many cases have an idea how often the subexpression will be executed.
I read your 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."
in [1]. I was thinking that if we can do such a replacement sooner,
for example once we know the num_calls for the subplans, Unknown if it
is possible though. If we can, then we can handle the issue here as well.
The attached is a very PoC version, I'm not sure if it is the right direction
to go.
The idea behind it is if we have a RelOptInfo which have some AlternativeSubPlan,
and assume these subplans have some correlated vars which can be expressed as
deps_relids. Then we can convert the AlternativeSubPlan to SubPlan once
bms_is_subset(deps_relids, rel->relids). My patch is able to fix the issue reported
here and it only converts the AlternativeSubPlan in rel->reltarget for demo purpose.
