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 | CAMbWs49D6VYwf3twjcrNAWY-a=QD482iwrZOVgMD7WkCYNsk1g@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: BUG #19102: Assertion failure in generate_orderedappend_paths with aggregate pushdown (Alexander Korotkov <aekorotkov@gmail.com>) |
| Список | pgsql-bugs |
On Wed, Nov 5, 2025 at 5:30 PM Alexander Korotkov <aekorotkov@gmail.com> wrote: > Hmm... I don't quite get the point, because with my patch > get_cheapest_fractional_path_for_pathkeys() would allow passing tuple > fraction as either fraction of tuples or absolute number of tuples in > the same way as grouping_planner() (see its header comment). Now I see what you mean. However, I'm still not sure this is a better approach, especially since the tuple fraction could end up being calculated twice in the build_minmax_path() case. Also, I still don't think the comment in your patch is correct. The comment for get_cheapest_fractional_path_for_pathkeys() states: * See compare_fractional_path_costs() for the interpretation of the fraction * parameter. However, in cases where the fraction is greater than 1, compare_fractional_path_costs() interprets it as 1, whereas the get_cheapest_fractional_path_for_pathkeys() function in your patch interprets it as the absolute number of tuples to be retrieved. > But given we need to backpatch this, we should avoid changing > functions signatures. So, please, go ahead pushing your patch. I've pushed and backpatched v2-0001. Thanks to everyone for the reviews, and to Kuntal for the report and reproduction script. I've also pushed 0002, but only to master. I'm a bit hesitant to backpatch it given the lack of field complaints. If it later turns out that a backpatch is needed, we can do that then. - Richard
В списке pgsql-bugs по дате отправления: