Re: [HACKERS] why not parallel seq scan for slow functions

On Fri, Mar 30, 2018 at 1:41 AM, Robert Haas wrote: > On Thu, Mar 29, 2018 at 12:55 AM, Amit Kapila wrote: >> I think that is under acceptable range. I am seeing few regression >> failures with the patch series. The order of targetlist seems to

Re: [HACKERS] why not parallel seq scan for slow functions

On Thu, Mar 29, 2018 at 12:55 AM, Amit Kapila wrote: > I think that is under acceptable range. I am seeing few regression > failures with the patch series. The order of targetlist seems to have > changed for Remote SQL. Kindly find the failure report attached. I >

Re: [HACKERS] why not parallel seq scan for slow functions

On Thu, Mar 29, 2018 at 2:31 AM, Robert Haas wrote: > On Wed, Mar 28, 2018 at 3:06 AM, Amit Kapila wrote: >> >> The above block takes 43700.0289 ms on Head and 45025.3779 ms with the >> patch which is approximately 3% regression. > > Thanks for the

Re: [HACKERS] why not parallel seq scan for slow functions

On Wed, Mar 28, 2018 at 3:06 AM, Amit Kapila wrote: > Good idea, such an optimization will ensure that the cases reported > above will not have regression. However isn't it somewhat beating the > idea you are using in the patch which is to avoid modifying the path >

Re: [HACKERS] why not parallel seq scan for slow functions

On Tue, Mar 27, 2018 at 10:59 PM, Robert Haas wrote: > On Tue, Mar 27, 2018 at 7:42 AM, Robert Haas wrote: >> On Tue, Mar 27, 2018 at 1:45 AM, Amit Kapila wrote: >>> If we don't want to go with the upperrel logic, then maybe

Re: [HACKERS] why not parallel seq scan for slow functions

On Tue, Mar 27, 2018 at 7:42 AM, Robert Haas wrote: > On Tue, Mar 27, 2018 at 1:45 AM, Amit Kapila wrote: >> If we don't want to go with the upperrel logic, then maybe we should >> consider just merging some of the other changes from my previous

Re: [HACKERS] why not parallel seq scan for slow functions

On Tue, Mar 27, 2018 at 1:45 AM, Amit Kapila wrote: > If we don't want to go with the upperrel logic, then maybe we should > consider just merging some of the other changes from my previous patch > in 0003* patch you have posted and then see if it gets rid of all the >

Re: [HACKERS] why not parallel seq scan for slow functions

On Tue, Mar 27, 2018 at 3:08 AM, Robert Haas wrote: > On Sat, Mar 24, 2018 at 9:40 AM, Amit Kapila wrote: >> For me, it is equivalent to the master. The average of ten runs on >> the master is 20664.3683 and with all the patches applied it is >>

Re: [HACKERS] why not parallel seq scan for slow functions

On Sat, Mar 24, 2018 at 9:40 AM, Amit Kapila wrote: > For me, it is equivalent to the master. The average of ten runs on > the master is 20664.3683 and with all the patches applied it is > 20590.4734. I think there is some run-to-run variation, but more or > less there

Re: [HACKERS] why not parallel seq scan for slow functions

On Sat, Mar 24, 2018 at 8:41 AM, Robert Haas wrote: > On Fri, Mar 23, 2018 at 12:12 AM, Amit Kapila wrote: >> Yeah, sometimes that kind of stuff change performance characteristics, >> but I think what is going on here is that create_projection_plan

Re: [HACKERS] why not parallel seq scan for slow functions

On Fri, Mar 23, 2018 at 12:12 AM, Amit Kapila wrote: > Yeah, sometimes that kind of stuff change performance characteristics, > but I think what is going on here is that create_projection_plan is > causing the lower node to build physical tlist which takes some >

Re: [HACKERS] why not parallel seq scan for slow functions

On Tue, Mar 20, 2018 at 1:23 AM, Robert Haas wrote: > On Sat, Mar 17, 2018 at 1:16 AM, Amit Kapila wrote: >> Test-1 >> -- >> DO $$ >> DECLARE count integer; >> BEGIN >> For count In 1..100 Loop >> Execute 'explain Select ten from

Re: [HACKERS] why not parallel seq scan for slow functions

On Sat, Mar 17, 2018 at 1:16 AM, Amit Kapila wrote: > Test-1 > -- > DO $$ > DECLARE count integer; > BEGIN > For count In 1..100 Loop > Execute 'explain Select ten from tenk1'; > END LOOP; > END; > $$; > > In the above block, I am explaining the simple

Re: [HACKERS] why not parallel seq scan for slow functions

On Fri, Mar 16, 2018 at 3:36 PM, Amit Kapila wrote: > On Wed, Mar 14, 2018 at 12:01 AM, Robert Haas wrote: >> >> 0003 introduces a new upper relation to represent the result of >> applying the scan/join target to the topmost scan/join relation.

Re: [HACKERS] why not parallel seq scan for slow functions

On Fri, Mar 16, 2018 at 6:06 AM, Amit Kapila wrote: > I think in the patch series this is the questionable patch wherein it > will always add an additional projection path (whether or not it is > required) to all Paths (partial and non-partial) for the scanjoin rel > and

Re: [HACKERS] why not parallel seq scan for slow functions

On Wed, Mar 14, 2018 at 12:01 AM, Robert Haas wrote: > > 0003 introduces a new upper relation to represent the result of > applying the scan/join target to the topmost scan/join relation. I'll > explain further down why this seems to be needed. Since each path > must

Re: [HACKERS] why not parallel seq scan for slow functions

On Wed, Feb 14, 2018 at 5:37 AM, Amit Kapila wrote: > Your concern is valid, but isn't the same problem exists in another > approach as well, because in that also we can call > adjust_paths_for_srfs after generating gather path which means that we > might lose some

Re: [HACKERS] why not parallel seq scan for slow functions

On Sun, Mar 11, 2018 at 5:49 PM, Amit Kapila wrote: > >> +/* Add projection step if needed */ >> +if (target && simple_gather_path->pathtarget != target) >> >> If the target was copied someplace, this test will fail. Probably we want to >> check containts of the

Re: [HACKERS] why not parallel seq scan for slow functions

On Thu, Feb 15, 2018 at 4:18 PM, Ashutosh Bapat wrote: > > After recent commits, the patch doesn't get applied cleanly, so rebased it and along the way addressed the comments raised by you. > Here are some comments on the patch. > > +/* > +

Re: [HACKERS] why not parallel seq scan for slow functions

On Mon, Feb 19, 2018 at 9:56 AM, Ashutosh Bapat wrote: > On Mon, Feb 19, 2018 at 9:35 AM, Ashutosh Bapat > wrote: >> On Sat, Feb 17, 2018 at 8:17 AM, Amit Kapila wrote: >>> On Fri, Feb 16, 2018 at 9:29

Re: [HACKERS] why not parallel seq scan for slow functions

On Mon, Feb 19, 2018 at 9:35 AM, Ashutosh Bapat wrote: > On Sat, Feb 17, 2018 at 8:17 AM, Amit Kapila wrote: >> On Fri, Feb 16, 2018 at 9:29 AM, Ashutosh Bapat >> wrote: >>> On Thu, Feb 15, 2018 at 7:47

Re: [HACKERS] why not parallel seq scan for slow functions

On Sat, Feb 17, 2018 at 8:17 AM, Amit Kapila wrote: > On Fri, Feb 16, 2018 at 9:29 AM, Ashutosh Bapat > wrote: >> On Thu, Feb 15, 2018 at 7:47 PM, Amit Kapila wrote: >>> On Thu, Feb 15, 2018 at 4:18 PM, Ashutosh

Re: [HACKERS] why not parallel seq scan for slow functions

On Fri, Feb 16, 2018 at 9:29 AM, Ashutosh Bapat wrote: > On Thu, Feb 15, 2018 at 7:47 PM, Amit Kapila wrote: >> On Thu, Feb 15, 2018 at 4:18 PM, Ashutosh Bapat >> wrote: >>> I happened to look at the

Re: [HACKERS] why not parallel seq scan for slow functions

On Thu, Feb 15, 2018 at 7:47 PM, Amit Kapila wrote: > On Thu, Feb 15, 2018 at 4:18 PM, Ashutosh Bapat > wrote: >> I happened to look at the patch for something else. But here are some >> comments. If any of those have been already

Re: [HACKERS] why not parallel seq scan for slow functions

On Thu, Feb 15, 2018 at 4:18 PM, Ashutosh Bapat wrote: > I happened to look at the patch for something else. But here are some > comments. If any of those have been already discussed, please feel > free to ignore. I have gone through the thread cursorily, so I

Re: [HACKERS] why not parallel seq scan for slow functions

I happened to look at the patch for something else. But here are some comments. If any of those have been already discussed, please feel free to ignore. I have gone through the thread cursorily, so I might have missed something. In grouping_planner() we call query_planner() first which builds the

Re: [HACKERS] why not parallel seq scan for slow functions

On Fri, Feb 2, 2018 at 12:15 AM, Robert Haas wrote: > On Wed, Jan 31, 2018 at 11:48 PM, Amit Kapila wrote: > > The other cases aren't so clear. In the case of the first call within > create_ordered_paths, there's no loss in the !is_sorted case

Re: [HACKERS] why not parallel seq scan for slow functions

On Wed, Jan 31, 2018 at 11:48 PM, Amit Kapila wrote: > I can see what you have in mind, but I think we still need to change > the parallel safety flag of the path if *_target is not parallel safe > either inside apply_projection_to_path or may be outside where it is >

Re: [HACKERS] why not parallel seq scan for slow functions

On Tue, Jan 30, 2018 at 3:30 AM, Robert Haas wrote: > On Sun, Jan 28, 2018 at 10:13 PM, Amit Kapila wrote: >> If we want to get rid of Gather (Merge) checks in >> apply_projection_to_path(), then we need some way to add a projection >> path to the

Re: [HACKERS] why not parallel seq scan for slow functions

On Sun, Jan 28, 2018 at 10:13 PM, Amit Kapila wrote: > If we want to get rid of Gather (Merge) checks in > apply_projection_to_path(), then we need some way to add a projection > path to the subpath of gather node even if that is capable of > projection as we do now. I

Re: [HACKERS] why not parallel seq scan for slow functions

On Sat, Jan 27, 2018 at 2:50 AM, Robert Haas wrote: > On Tue, Jan 2, 2018 at 6:38 AM, Amit Kapila wrote: >> [ new patch ] > > I think that grouping_planner() could benefit from a slightly more > extensive rearrangement. With your patch applied,

Re: [HACKERS] why not parallel seq scan for slow functions

On Tue, Jan 2, 2018 at 6:38 AM, Amit Kapila wrote: > [ new patch ] I think that grouping_planner() could benefit from a slightly more extensive rearrangement. With your patch applied, the order of operations is: 1. compute the scan/join target 2. apply the scan/join

Re: [HACKERS] why not parallel seq scan for slow functions

On Fri, Dec 29, 2017 at 7:56 PM, Marina Polyakova wrote: > Hello everyone in this thread! > > On 29-11-2017 8:01, Michael Paquier wrote: >> >> Moved to next CF for extra reviews. > > > Amit, I would like to ask some questions about your patch (and can you > please

Re: [HACKERS] why not parallel seq scan for slow functions

Hello everyone in this thread! On 29-11-2017 8:01, Michael Paquier wrote: Moved to next CF for extra reviews. Amit, I would like to ask some questions about your patch (and can you please rebase it on the top of the master?): 1) + path->total_cost -= (target->cost.per_tuple -