diff options
| author | Tom Lane <tgl@sss.pgh.pa.us> | 2021-02-04 19:12:09 -0500 |
|---|---|---|
| committer | Tom Lane <tgl@sss.pgh.pa.us> | 2021-02-04 19:12:09 -0500 |
| commit | 10fcb83da6a7c5328f61ca7fb60f78c57db1bd58 (patch) | |
| tree | d21c9b67782c3a03efc446604dc8cb1dabfb031f /src | |
| parent | 57868d957eb8320f924bc8453372cf9954e9a338 (diff) | |
Fix YA incremental sort bug.
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
Diffstat (limited to 'src')
| -rw-r--r-- | src/backend/executor/nodeIncrementalSort.c | 7 | ||||
| -rw-r--r-- | src/test/regress/expected/incremental_sort.out | 11 | ||||
| -rw-r--r-- | src/test/regress/sql/incremental_sort.sql | 3 |
3 files changed, 21 insertions, 0 deletions
diff --git a/src/backend/executor/nodeIncrementalSort.c b/src/backend/executor/nodeIncrementalSort.c index b53f8a01810..360aad32c5c 100644 --- 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 index a8cbfd9f5f9..d5745838440 100644 --- 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 index 62a037b0cfb..9965fcd7776 100644 --- 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 |