Re: Problem about postponing gathering partial paths for topmost scan/join rel

2022-07-30 Thread Tom Lane
Antonin Houska writes: > I'm going to set the CF entry to "ready for committer'". I pushed this with some editorialization: * Grepping found another caller of generate_useful_gather_paths with the exact same bug, in geqo_eval.c. (A wise man once said that the most powerful bug-finding heuristic

Re: Problem about postponing gathering partial paths for topmost scan/join rel

2022-07-18 Thread Antonin Houska
Richard Guo wrote: > On Fri, Jul 15, 2022 at 5:00 PM Richard Guo wrote: > > On Fri, Jul 15, 2022 at 4:03 PM Richard Guo wrote: > > On Thu, Jul 14, 2022 at 10:02 PM Antonin Houska wrote: > > I'd prefer a test that demonstrates that the Gather node at the top of the > "subproblem plan" is

Re: Problem about postponing gathering partial paths for topmost scan/join rel

2022-07-18 Thread Richard Guo
On Fri, Jul 15, 2022 at 5:00 PM Richard Guo wrote: > On Fri, Jul 15, 2022 at 4:03 PM Richard Guo > wrote: > >> On Thu, Jul 14, 2022 at 10:02 PM Antonin Houska wrote: >> >>> I'd prefer a test that demonstrates that the Gather node at the top of >>> the >>> "subproblem plan" is useful purely from

Re: Problem about postponing gathering partial paths for topmost scan/join rel

2022-07-15 Thread Richard Guo
On Fri, Jul 15, 2022 at 4:03 PM Richard Guo wrote: > > On Thu, Jul 14, 2022 at 10:02 PM Antonin Houska wrote: > >> I'd prefer a test that demonstrates that the Gather node at the top of the >> "subproblem plan" is useful purely from the *cost* perspective, rather >> than >> due to executor limit

Re: Problem about postponing gathering partial paths for topmost scan/join rel

2022-07-15 Thread Richard Guo
On Thu, Jul 14, 2022 at 10:02 PM Antonin Houska wrote: > I'd prefer a test that demonstrates that the Gather node at the top of the > "subproblem plan" is useful purely from the *cost* perspective, rather than > due to executor limitation. This patch provides an additional path (Gather atop of

Re: Problem about postponing gathering partial paths for topmost scan/join rel

2022-07-14 Thread Antonin Houska
Richard Guo wrote: > On Wed, Jul 28, 2021 at 3:42 PM Richard Guo wrote: > > To fix this problem, I'm thinking we can leverage 'root->all_baserels' > to tell if we are at the topmost scan/join rel, something like: > > --- a/src/backend/optimizer/path/allpaths.c > +++ b/src/backend/optimizer

Re: Problem about postponing gathering partial paths for topmost scan/join rel

2021-07-30 Thread Richard Guo
On Wed, Jul 28, 2021 at 3:42 PM Richard Guo wrote: > To fix this problem, I'm thinking we can leverage 'root->all_baserels' > to tell if we are at the topmost scan/join rel, something like: > > --- a/src/backend/optimizer/path/allpaths.c > +++ b/src/backend/optimizer/path/allpaths.c > @@ -3041,7

Problem about postponing gathering partial paths for topmost scan/join rel

2021-07-28 Thread Richard Guo
Hi all, In commit 3f90ec85 we are trying to postpone gathering partial paths for topmost scan/join rel until we know the final targetlist, in order to allow more accurate costing of parallel paths. We do this by the following code snippet in standard_join_search: + /* +* Except for the topm