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:14 -0500 |
| commit | 82e0e29308dedbc6000e73329beb112ae7e1ad39 (patch) | |
| tree | 8581de677c324f051ce021eac95e56bc20eb7bf4 /src | |
| parent | c34787f910585f82320f78b0afd53a6a170aa229 (diff) | |
| download | postgresql-82e0e29308dedbc6000e73329beb112ae7e1ad39.tar.gz | |
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 73e42d7945..82fa800cb1 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 a8cbfd9f5f..d574583844 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 62a037b0cf..9965fcd777 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 |