opt: disable GenerateParameterizedJoin for custom query plans

[mgartner]

opt: remove documentation of old flags

In #85935 we introduced the set flag to set session settings in
optimizer tests and a few flags that were already controlling session
settings were removed. The documentation of those old flags has been
removed.

Release note: None

opt: disable GenerateParameterizedJoin for custom query plans

The exploration rule GenerateParameterizedJoin is now disabled when a
custom query plan is being built. The mechanism for toggling this rule
is using either Optimizer.Optimize() which disables the rule or
Optimizer.OptimizeGeneric() which enables the rule. Note that the rule
is not toggled by the plan_cache_mode session setting, because the
auto mode may build custom or generic query plans. Also, changing the
plan_cache_mode session setting does not make memos stale as other
session settings do, because generic memos are kept separate from the
unoptimized memos reused to build custom plans.

Epic: None

Release note: None

opt: add "Generic" optgen tag

Optgen now supports the "Generic" tag and the IsGeneric() method has
been added to RuleName which returns true if the rule has the tag. The
new method is used to disable rules that optimize generic query plans
when custom plans are being built.

Release note: None

[cockroach-teamcity]

This change is 

[mgartner]

I'll backport only the second commit to 23.2 and 24.1. See the conversation in #128085 (review).

[DrewKimball]

Reviewed 1 of 1 files at r1, 6 of 6 files at r2, 3 of 3 files at r3, all commit messages.
Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @mgartner, @michae2, and @rytaft)

---

pkg/sql/opt/xform/optimizer.go line 244 at r2 (raw file):

	originalMatchedRule := o.matchedRule
	defer func() { o.matchedRule = originalMatchedRule }()
	o.matchedRule = func(r opt.RuleName) bool {

[nit] I'm open to pushback, but I'd prefer to make generic rule checks part of the generated rule code (probably here and here). We could use the Generic tag to do that. For the backportable portion, we could just make the check part of the GenerateParameterizedJoin rule as a custom func. What do you think?

[rytaft]

pkg/sql/opt/xform/optimizer.go line 244 at r2 (raw file):

Previously, DrewKimball (Drew Kimball) wrote…

[nit] I'm open to pushback, but I'd prefer to make generic rule checks part of the generated rule code (probably here and here). We could use the Generic tag to do that. For the backportable portion, we could just make the check part of the GenerateParameterizedJoin rule as a custom func. What do you think?

Any reason you can't just check the value of plan_cache_mode inside GenerateParameterizedJoin? I realize that will miss certain cases for auto, but I feel like it will be a smaller and more easily backportable change. I guess another option is to do the small change for the backport and do something like this for 24.2 and beyond.

[mgartner]

pkg/sql/opt/xform/optimizer.go line 244 at r2 (raw file):

[nit] I'm open to pushback, but I'd prefer to make generic rule checks part of the generated rule code (probably here and here). We could use the Generic tag to do that. For the backportable portion, we could just make the check part of the GenerateParameterizedJoin rule as a custom func. What do you think?

I agree with avoiding use of o.matchedRule like this. But the question is how to plumb a genericRulesEnabled bool into that part of xform? I didn't love the idea of setting a bool field on Optimizer or Memo on this because it seemed tricky to reason about when to reset this value given that both can be reused in some cases. I suppose it might be find to set on the Memo because a generic memo will remain generic and never be reoptimized?

Any reason you can't just check the value of plan_cache_mode inside GenerateParameterizedJoin? I realize that will miss certain cases for auto, but I feel like it will be a smaller and more easily backportable change. I guess another option is to do the small change for the backport and do something like this for 24.2 and beyond.

Ya, we could just check plan_cache_mode=custom for the backport. The rule may still fire in some cases when plan_cache_mode=auto when we don't want or need it to. That's probably an acceptable risk though.

[michae2]

Why doesn't the HasPlaceholdersOrStableExprs check at the beginning of the rule suffice for disabling the rule when optimizing custom plans? It seems like that check will always be false when optimizing a custom plan. But maybe I'm missing something?

Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @DrewKimball and @rytaft)

[mgartner]

Why doesn't the HasPlaceholdersOrStableExprs check at the beginning of the rule suffice for disabling the rule when optimizing custom plans? It seems like that check will always be false when optimizing a custom plan. But maybe I'm missing something?

It mostly does. However, if we fail to fold a stable function during normalization, then we'll leave the unfolded function in the memo. In those rare cases, GenerateParameterizedJoin could fire during exploration even if plan_cache_mode=force_custom_plan. Maybe that's not a case worth worrying about?

In any case, I think the simplest and safest thing to do is what @rytaft suggests and add a simple check for plan_cache_mode. This will be sufficient to prevent the backports from causing any regressions.

[mgartner]

Please review the alternative PR #129050.