Fix executor prune failure when plan already pruned

alvherre · alvherre · commit 1eb9221585c2 · 2018-08-16T12:53:43.000-03:00
In a multi-layer partitioning setup, if at plan time all the sub-partitions are pruned but the intermediate one remains, the executor later throws a spurious error that there's nothing to prune. That is correct, but there's no reason to throw an error. Therefore, don't. Reported-by: Andreas Seltenreich <seltenreich@gmx.de> Author: David Rowley <david.rowley@2ndquadrant.com> Discussion: https://postgr.es/m/87in4h98i0.fsf@ansel.ydns.eu
diff --git a/src/backend/executor/execPartition.c b/src/backend/executor/execPartition.c
@@ -1886,8 +1886,13 @@ find_matching_subplans_recurse(PartitionPruningData *prunedata,
 											   initial_prune, validsubplans);
 			else
 			{
-				/* Shouldn't happen */
-				elog(ERROR, "partition missing from subplans");
+				/*
+				 * We get here if the planner already pruned all the sub-
+				 * partitions for this partition.  Silently ignore this
+				 * partition in this case.  The end result is the same: we
+				 * would have pruned all partitions just the same, but we
+				 * don't have any pruning steps to execute to verify this.
+				 */
 			}
 		}
 	}
diff --git a/src/test/regress/expected/partition_prune.out b/src/test/regress/expected/partition_prune.out
@@ -3570,3 +3570,21 @@ execute q (1, 1);
 
 reset plan_cache_mode;
 drop table p, q;
+-- Ensure run-time pruning works correctly when we match a partitioned table
+-- on the first level but find no matching partitions on the second level.
+create table listp (a int, b int) partition by list (a);
+create table listp1 partition of listp for values in(1);
+create table listp2 partition of listp for values in(2) partition by list(b);
+create table listp2_10 partition of listp2 for values in (10);
+explain (analyze, costs off, summary off, timing off)
+select * from listp where a = (select 2) and b <> 10;
+                QUERY PLAN                 
+-------------------------------------------
+ Append (actual rows=0 loops=1)
+   InitPlan 1 (returns $0)
+     ->  Result (actual rows=1 loops=1)
+   ->  Seq Scan on listp1 (never executed)
+         Filter: ((b <> 10) AND (a = $0))
+(5 rows)
+
+drop table listp;
diff --git a/src/test/regress/sql/partition_prune.sql b/src/test/regress/sql/partition_prune.sql
@@ -946,3 +946,15 @@ execute q (1, 1);
 
 reset plan_cache_mode;
 drop table p, q;
+
+-- Ensure run-time pruning works correctly when we match a partitioned table
+-- on the first level but find no matching partitions on the second level.
+create table listp (a int, b int) partition by list (a);
+create table listp1 partition of listp for values in(1);
+create table listp2 partition of listp for values in(2) partition by list(b);
+create table listp2_10 partition of listp2 for values in (10);
+
+explain (analyze, costs off, summary off, timing off)
+select * from listp where a = (select 2) and b <> 10;
+
+drop table listp;

Original file line number	Diff line number	Diff line change
`@@ -1886,8 +1886,13 @@ find_matching_subplans_recurse(PartitionPruningData *prunedata,`
`1886`	`1886`	`initial_prune, validsubplans);`
`1887`	`1887`	`else`
`1888`	`1888`	`{`
`1889`		`- /* Shouldn't happen */`
`1890`		`- elog(ERROR, "partition missing from subplans");`
	`1889`	`+ /*`
	`1890`	`+ * We get here if the planner already pruned all the sub-`
	`1891`	`+ * partitions for this partition. Silently ignore this`
	`1892`	`+ * partition in this case. The end result is the same: we`
	`1893`	`+ * would have pruned all partitions just the same, but we`
	`1894`	`+ * don't have any pruning steps to execute to verify this.`
	`1895`	`+ */`
`1891`	`1896`	`}`
`1892`	`1897`	`}`
`1893`	`1898`	`}`