Horton

Re: BUG #19102: Assertion failure in generate_orderedappend_paths with aggregate pushdown

Alexander Korotkov <aekorotkov@gmail.com>

View thread
From: Alexander Korotkov <aekorotkov@gmail.com>
To: Andrei Lepikhov <lepihov@gmail.com>
Cc: Richard Guo <guofenglinux@gmail.com>, pgsql-bugs@lists.postgresql.org, akorotkov@postgresql.org, Kuntal Ghosh <kuntalghosh.2007@gmail.com>
Date: 2025-11-04T23:41:13Z
Lists: pgsql-bugs

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix assertion failure in generate_orderedappend_paths()

  2. Avoid creating duplicate ordered append paths

Attachments

On Tue, Nov 4, 2025 at 3:43 PM Andrei Lepikhov <lepihov@gmail.com> wrote:
> On 4/11/2025 08:44, Richard Guo wrote:
> > Any thoughts?The first patch looks good, but I still have a couple of questions.
> 1. We don't use parameterised paths in MergeAppend yet. I wonder if it
> could be nudged by spreading the use of partitioned tables with foreign
> partitions. Do you think, in such a case, the usage of
> cheapest_total->rows will stay correct? It seems that the parameterised
> path has much less estimation than the RelOptInfo...
>
> 2. I understand why the upper relation has unset nrows. However, it may
> be more accurate to set row estimation for a pushing-down upper
> RelOptInfo. Or, at least, describe in comments why this is desirable
> behaviour. It would be profitable, at least, for extension developers.

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.

> I also support the second patch. With many partitions, it allows us to
> save a significant amount of CPU cycles.

+1

------
Regards,
Alexander Korotkov
Supabase