Re: BUG #19102: Assertion failure in generate_orderedappend_paths with aggregate pushdown
| От | Richard Guo |
|---|---|
| Тема | Re: BUG #19102: Assertion failure in generate_orderedappend_paths with aggregate pushdown |
| Дата | |
| Msg-id | CAMbWs49GqiLdhH77BPHfqE+7KGN2H67pvKamYWeVKGZv_iPLZQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: BUG #19102: Assertion failure in generate_orderedappend_paths with aggregate pushdown (Alexander Korotkov <aekorotkov@gmail.com>) |
| Ответы |
Re: BUG #19102: Assertion failure in generate_orderedappend_paths with aggregate pushdown
|
| Список | pgsql-bugs |
On Wed, Nov 5, 2025 at 8:41 AM Alexander Korotkov <aekorotkov@gmail.com> wrote: > I wonder if get_cheapest_fractional_path_for_pathkeys() should start > the same as get_cheapest_fractional_path() with calculation of the > tuple fraction. We could change its first argument to RelOptInfo, > since the both callers get pathlist from RelOptInfo. See attached > draft patch implementing this. No, I don't think your patch is correct. With your changes, the meaning of the fraction parameter in get_cheapest_fractional_path_for_pathkeys() becomes quite ambiguous. In the build_minmax_path() case, this parameter represents the fraction of tuples we want to retrieve, and thus converting the fraction again within get_cheapest_fractional_path_for_pathkeys() is incorrect. However, in the generate_orderedappend_paths() case, the parameter is interpreted the same way as in grouping_planner(). I don't think it's a good design choice for the same function parameter to be interpreted differently depending on where it is called. In addition, your patch doesn't update this function's comment to provide a correct explanation of the fraction parameter. - Richard
В списке pgsql-bugs по дате отправления: