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 по дате отправления: