Don't try to generate generic plans with GPORCA.

If you have plan_cache_mode=auto, which is the default, never try to
generate "generic" plans. GPORCA doesn't support Param nodes, so it will
always fall back to the Postgres planner. What happened without this patch
was that the backend code would compare the cost of the custom plan
generated with GPORCA with the cost of a generic plan generated with the
Postgres planner, and that doesn't make much sense because the GPORCA has
a very different cost model from the Postgres planner.

No test, because it would be quite tedious and fragile to write one, and
the code change seems simple enough.

I bumped into this while hacking on PR #10676, which changes the Postgres
planner's cost model. There's a test in 'direct_dispatch' for the generic
plan generation, and it started to fail because with the planner cost
model changes, the Postgres planner's generic plan started to look cheaper
than the custom plan generated with GPORCA. So we do have some test
coverage for this, although accidental.
Reviewed-by: NVenkatesh Raghavan <vraghavan@pivotal.io>

src/backend/gpopt/translate/CTranslatorScalarToDXL.cpp

@@ -323,6 +323,9 @@ CTranslatorScalarToDXL::TranslateScalarToDXL
 		// give a better message.
 		if (tag == T_Param)
 		{
+			// Note: The choose_custom_plan() function in plancache.c
+			// knows that GPORCA doesn't support Params. If you lift this
+			// limitation, adjust choose_custom_plan() accordingly!
 			GPOS_RAISE(gpdxl::ExmaDXL, gpdxl::ExmiPlStmt2DXLConversion, GPOS_WSZ_LIT("Query Parameter"));
 		}
 		else

src/backend/utils/cache/plancache.c

@@ -1104,6 +1104,25 @@ choose_custom_plan(CachedPlanSource *plansource, ParamListInfo boundParams, Into
 	if (plansource->cursor_options & CURSOR_OPT_CUSTOM_PLAN)
 		return true;
 
+	/*
+	 * GPORCA doesn't support Params at all, so there's no hope of generating
+	 * a generic plan. We could generate a generic plan with the Postgres
+	 * planner, but the cost model between GPORCA and the Postgres planner is
+	 * is different, so comparing the costs between plans generated with
+	 * GPORCA and the Postgres planner would not be sensible. Therefore always
+	 * continue with custom plans if GPORCA is enabled.
+	 *
+	 * Arguably we should check if the custom plan was actually generated with
+	 * GPORCA or if GPORCA fell back to the Postgres planner. If the custom
+	 * plan was was generated with the Postgres planner, even though the
+	 * optimizer GUC was enabled, then it would be fair to compare it with a
+	 * generic plan also generated with the Postgres planner. But it seems
+	 * more straightforward that if "optimizer=on" and "plan_cache_mode=auto",
+	 * you always get custom plans.
+	 */
+	if (optimizer)
+		return true;
+
 	/* Generate custom plans until we have done at least 5 (arbitrary) */
 	if (plansource->num_custom_plans < 5)
 		return true;