Fix YA incremental sort bug.

tglsfdc · tglsfdc · commit 10fcb83da6a7 · 2021-02-04T19:12:09.000-05:00
switchToPresortedPrefixMode() did the wrong thing if it detected a batch boundary just at the last tuple of a fullsort group. The initially-reported symptom was a "retrieved too many tuples in a bounded sort" error, but the test case added here just silently gives the wrong answer without this patch. I (tgl) am not really happy about committing this patch without review from the incremental-sort authors, but they seem AWOL and we are hard against a release deadline. This does demonstrably make some cases better, anyway. Per bug #16846 from Yoran Heling. Back-patch to v13 where incremental sort was introduced. Neil Chen Discussion: https://postgr.es/m/16846-ae49f51ac379a4cb@postgresql.org
diff --git a/src/backend/executor/nodeIncrementalSort.c b/src/backend/executor/nodeIncrementalSort.c
@@ -394,6 +394,13 @@ switchToPresortedPrefixMode(PlanState *pstate)
 				 * current prefix key group.
 				 */
 				ExecClearTuple(node->group_pivot);
+
+				/*
+				 * Also make sure we take the didn't-consume-all-the-tuples
+				 * path below, even if this happened to be the last tuple of
+				 * the batch.
+				 */
+				lastTuple = false;
 				break;
 			}
 		}
diff --git a/src/test/regress/expected/incremental_sort.out b/src/test/regress/expected/incremental_sort.out
@@ -675,6 +675,17 @@ select * from (select * from t order by a) s order by a, b limit 70;
  9 | 70
 (70 rows)
 
+-- Checks case where we hit a group boundary at the last tuple of a batch.
+select * from (select * from t order by a) s order by a, b limit 5;
+ a | b 
+---+---
+ 1 | 1
+ 2 | 2
+ 3 | 3
+ 4 | 4
+ 9 | 5
+(5 rows)
+
 -- Test rescan.
 begin;
 -- We force the planner to choose a plan with incremental sort on the right side
diff --git a/src/test/regress/sql/incremental_sort.sql b/src/test/regress/sql/incremental_sort.sql
@@ -149,6 +149,9 @@ insert into t(a, b) select (case when i < 5 then i else 9 end), i from generate_
 analyze t;
 explain (costs off) select * from (select * from t order by a) s order by a, b limit 70;
 select * from (select * from t order by a) s order by a, b limit 70;
+-- Checks case where we hit a group boundary at the last tuple of a batch.
+select * from (select * from t order by a) s order by a, b limit 5;
+
 -- Test rescan.
 begin;
 -- We force the planner to choose a plan with incremental sort on the right side

Original file line number	Diff line number	Diff line change
`@@ -394,6 +394,13 @@ switchToPresortedPrefixMode(PlanState *pstate)`
`394`	`394`	`* current prefix key group.`
`395`	`395`	`*/`
`396`	`396`	`ExecClearTuple(node->group_pivot);`
	`397`	`+`
	`398`	`+ /*`
	`399`	`+ * Also make sure we take the didn't-consume-all-the-tuples`
	`400`	`+ * path below, even if this happened to be the last tuple of`
	`401`	`+ * the batch.`
	`402`	`+ */`
	`403`	`+ lastTuple = false;`
`397`	`404`	`break;`
`398`	`405`	`}`
`399`	`406`	`}`