Append nodes bearing non-relation RTIs are ordinary

this isn't really a correct fix

1 files changed, 32 insertions, 1 deletions

diff --git a/contrib/pg_plan_advice/pgpa_scan.c b/contrib/pg_plan_advice/pgpa_scan.c
index 61455c1874..5d0c6f5043 100644
--- a/contrib/pg_plan_advice/pgpa_scan.c
+++ b/contrib/pg_plan_advice/pgpa_scan.c
@@ -97,7 +97,38 @@ pgpa_build_scan(PlannedStmt *pstmt, Plan *plan, ElidedNode *elided_node,
 				break;
 			case T_Append:
 			case T_MergeAppend:
-				strategy = PGPA_SCAN_PARTITIONWISE;
+				{
+					int			first_rti;
+					RangeTblEntry *first_rte;
+
+					first_rti = bms_next_member(relids, -1);
+					first_rte = rt_fetch(first_rti, pstmt->rtable);
+
+					/*
+					 * Append and MergeAppend nodes can be the result either
+					 * of set operations or of inheritance expansion. In the
+					 * latter case, this plan node is telling us that the relid
+					 * set found in the plan node was handled partitionwise,
+					 * but in the former, it isn't. Even if the set operations
+					 * planner has multiple ways to execute some set operation,
+					 * we lack the ability to describe what it decided here,
+					 * and hence just label this as an ordinary scan.
+					 *
+					 * XXX. This breaks with a single Append node that involves
+					 * both set operations and inheritance expansion. Consider:
+					 *
+					 * create table foo (a int) partition by range (a);
+					 * create table foo0 partition of foo for values
+					 *      from (0) to (1000);
+					 * create table foo1 partition of foo for values
+					 *      from (1000) to (2000);
+					 * explain select * from foo union all select 1;
+					 */
+					if (first_rte->rtekind == RTE_RELATION)
+						strategy = PGPA_SCAN_PARTITIONWISE;
+					else
+						strategy = PGPA_SCAN_ORDINARY;
+				}
 				break;
 			default:
 				strategy = PGPA_SCAN_ORDINARY;