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
-
Don't adjust ressortgroupref in generate_setop_child_grouplist()
- 7487044d6ccf 17.0 landed
-
Don't zero tuple_fraction when planning UNIONs with ORDER BYs
- 3b1a7eb28930 17.0 landed
-
Fix assert failure when planning setop subqueries with CTEs
- d5d2205c8ddc 17.0 landed
-
Allow planner to use Merge Append to efficiently implement UNION
- 66c0185a3d14 17.0 landed
-
Simplify PathKey checking code
- 0c444a70f2a7 17.0 landed
-
Clarify the 'rows' parameter in create_append_path
- 87027cb55bf7 17.0 landed