Re: Properly pathify the union planner

From: Richard Guo <guofenglinux(at)gmail(dot)com>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Properly pathify the union planner
Date: 2024-03-07 11:38:50
Message-ID: CAMbWs48R7Lp0CwcioeyenXHkrWdMfpOkaZ2OStjr7YeftRHe0Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Mar 7, 2024 at 7:16 PM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:

> On Thu, 15 Feb 2024 at 17:30, David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> >
> > On Tue, 6 Feb 2024 at 22:05, Richard Guo <guofenglinux(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kartyshov Ivan 2024-03-07 11:44:32 Re: [HACKERS] make async slave to wait for lsn to be replayed
Previous Message David Rowley 2024-03-07 11:28:49 Re: a wrong index choose when statistics is out of date