Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commitc1777f2

Browse files
author
Richard Guo
committed
Fix assertion failure in generate_orderedappend_paths()
In generate_orderedappend_paths(), there is an assumption that a childrelation's row estimate is always greater than zero. There is anAssert verifying this assumption, and the estimate is also used toconvert an absolute tuple count into a fraction.However, this assumption is not always valid -- for example, upperrelations can have their row estimates unset, resulting in a value ofzero. This can cause an assertion failure in debug builds or lead tothe tuple fraction being computed as infinity in production builds.To fix, use the row estimate from the cheapest_total path to computethe tuple fraction. The row estimate in this path should already havebeen forced to a valid value.In passing, update the comment for generate_orderedappend_paths() tonote that the function also considers the cheapest-fractional casewhen not all tuples need to be retrieved. That is, it collects allthe cheapest fractional paths and builds an ordered append path foreach interesting ordering.Backpatch to v18, where this issue was introduced.Bug: #19102Reported-by: Kuntal Ghosh <kuntalghosh.2007@gmail.com>Author: Richard Guo <guofenglinux@gmail.com>Reviewed-by: Kuntal Ghosh <kuntalghosh.2007@gmail.com>Reviewed-by: Andrei Lepikhov <lepihov@gmail.com>Discussion:https://postgr.es/m/19102-93480667e1200169@postgresql.orgBackpatch-through: 18
1 parenta4fd971 commitc1777f2

File tree

3 files changed

+49
-7
lines changed

3 files changed

+49
-7
lines changed

‎src/backend/optimizer/path/allpaths.c‎

Lines changed: 13 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -1810,9 +1810,11 @@ add_paths_to_append_rel(PlannerInfo *root, RelOptInfo *rel,
18101810
* We generate a path for each ordering (pathkey list) appearing in
18111811
* all_child_pathkeys.
18121812
*
1813-
* We consider both cheapest-startup and cheapest-total cases, ie, for each
1814-
* interesting ordering, collect all the cheapest startup subpaths and all the
1815-
* cheapest total paths, and build a suitable path for each case.
1813+
* We consider the cheapest-startup and cheapest-total cases, and also the
1814+
* cheapest-fractional case when not all tuples need to be retrieved. For each
1815+
* interesting ordering, we collect all the cheapest startup subpaths, all the
1816+
* cheapest total paths, and, if applicable, all the cheapest fractional paths,
1817+
* and build a suitable path for each case.
18161818
*
18171819
* We don't currently generate any parameterized ordered paths here. While
18181820
* it would not take much more code here to do so, it's very unclear that it
@@ -1977,14 +1979,18 @@ generate_orderedappend_paths(PlannerInfo *root, RelOptInfo *rel,
19771979
doublepath_fraction=root->tuple_fraction;
19781980

19791981
/*
1980-
* Merge Append considers only live children relations. Dummy
1981-
* relations must be filtered out before.
1982+
* We should not have a dummy child relation here. However,
1983+
* we cannot use childrel->rows to compute the tuple fraction,
1984+
* as childrel can be an upper relation with an unset row
1985+
* estimate. Instead, we use the row estimate from the
1986+
* cheapest_total path, which should already have been forced
1987+
* to a sane value.
19821988
*/
1983-
Assert(childrel->rows>0);
1989+
Assert(cheapest_total->rows>0);
19841990

19851991
/* Convert absolute limit to a path fraction */
19861992
if (path_fraction >=1.0)
1987-
path_fraction /=childrel->rows;
1993+
path_fraction /=cheapest_total->rows;
19881994

19891995
cheapest_fractional=
19901996
get_cheapest_fractional_path_for_pathkeys(childrel->pathlist,

‎src/test/regress/expected/partition_aggregate.out‎

Lines changed: 31 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -339,6 +339,37 @@ SELECT a FROM pagg_tab WHERE a < 3 GROUP BY a ORDER BY 1;
339339
2
340340
(3 rows)
341341

342+
-- Test partitionwise aggregation with ordered append path built from fractional paths
343+
EXPLAIN (COSTS OFF)
344+
SELECT count(*) FROM pagg_tab GROUP BY c ORDER BY c LIMIT 1;
345+
QUERY PLAN
346+
------------------------------------------------------------
347+
Limit
348+
-> Merge Append
349+
Sort Key: pagg_tab.c
350+
-> GroupAggregate
351+
Group Key: pagg_tab.c
352+
-> Sort
353+
Sort Key: pagg_tab.c
354+
-> Seq Scan on pagg_tab_p1 pagg_tab
355+
-> GroupAggregate
356+
Group Key: pagg_tab_1.c
357+
-> Sort
358+
Sort Key: pagg_tab_1.c
359+
-> Seq Scan on pagg_tab_p2 pagg_tab_1
360+
-> GroupAggregate
361+
Group Key: pagg_tab_2.c
362+
-> Sort
363+
Sort Key: pagg_tab_2.c
364+
-> Seq Scan on pagg_tab_p3 pagg_tab_2
365+
(18 rows)
366+
367+
SELECT count(*) FROM pagg_tab GROUP BY c ORDER BY c LIMIT 1;
368+
count
369+
-------
370+
250
371+
(1 row)
372+
342373
RESET enable_hashagg;
343374
-- ROLLUP, partitionwise aggregation does not apply
344375
EXPLAIN (COSTS OFF)

‎src/test/regress/sql/partition_aggregate.sql‎

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -76,6 +76,11 @@ EXPLAIN (COSTS OFF)
7676
SELECT aFROM pagg_tabWHERE a<3GROUP BY aORDER BY1;
7777
SELECT aFROM pagg_tabWHERE a<3GROUP BY aORDER BY1;
7878

79+
-- Test partitionwise aggregation with ordered append path built from fractional paths
80+
EXPLAIN (COSTS OFF)
81+
SELECTcount(*)FROM pagg_tabGROUP BY cORDER BY cLIMIT1;
82+
SELECTcount(*)FROM pagg_tabGROUP BY cORDER BY cLIMIT1;
83+
7984
RESET enable_hashagg;
8085

8186
-- ROLLUP, partitionwise aggregation does not apply

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp