Re: Properly pathify the union planner

Richard Guo <guofenglinux@gmail.com>

From: Richard Guo <guofenglinux@gmail.com>
To: David Rowley <dgrowleyml@gmail.com>
Cc: PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2024-03-07T11:38:50Z
Lists: pgsql-hackers
On Thu, Mar 7, 2024 at 7:16 PM David Rowley <dgrowleyml@gmail.com> wrote:

> On Thu, 15 Feb 2024 at 17:30, David Rowley <dgrowleyml@gmail.com> wrote:
> >
> > On Tue, 6 Feb 2024 at 22:05, Richard Guo <guofenglinux@gmail.com> wrote:
> > > I'm thinking that maybe it'd be better to move the work of sorting the
> > > subquery's paths to the outer query level, specifically within the
> > > build_setop_child_paths() function, just before we stick
> SubqueryScanPath
> > > on top of the subquery's paths.  I think this is better because:
> > >
> > > 1. This minimizes the impact on subquery planning and reduces the
> > > footprint within the grouping_planner() function as much as possible.
> > >
> > > 2. This can help avoid the aforementioned add_path() issue because the
> > > two involved paths will be structured as:
> >
> > Yes, this is a good idea. I agree with both of your points.
>
> > v2 attached.
>
> If anyone else or if you want to take another look, let me know soon.
> Otherwise, I'll assume that's the reviews over and I can take another
> look again.


Hi David,

I would like to have another look, but it might take several days.
Would that be too late?

Thanks
Richard

Commits

  1. Don't adjust ressortgroupref in generate_setop_child_grouplist()

  2. Don't zero tuple_fraction when planning UNIONs with ORDER BYs

  3. Fix assert failure when planning setop subqueries with CTEs

  4. Allow planner to use Merge Append to efficiently implement UNION

  5. Simplify PathKey checking code

  6. Clarify the 'rows' parameter in create_append_path