Re: parallel append vs. simple UNION ALL

2018-03-22 Thread Robert Haas
On Mon, Mar 19, 2018 at 11:57 AM, Robert Haas wrote: > On Fri, Mar 16, 2018 at 7:35 AM, Rajkumar Raghuwanshi > wrote: >> On Fri, Mar 9, 2018 at 1:04 AM, Robert Haas wrote: >>> Great. Committed 0001. Are you planning any further testing of this >>> patch series? >> >> Sorry I missed the mail. >

Re: parallel append vs. simple UNION ALL

2018-03-19 Thread Robert Haas
On Fri, Mar 16, 2018 at 7:35 AM, Rajkumar Raghuwanshi wrote: > On Fri, Mar 9, 2018 at 1:04 AM, Robert Haas wrote: >> Great. Committed 0001. Are you planning any further testing of this >> patch series? > > Sorry I missed the mail. > Yes, I have further tested patches and find no more issues. O

Re: parallel append vs. simple UNION ALL

2018-03-16 Thread Rajkumar Raghuwanshi
On Fri, Mar 9, 2018 at 1:04 AM, Robert Haas wrote: > Great. Committed 0001. Are you planning any further testing of this > patch series? Sorry I missed the mail. Yes, I have further tested patches and find no more issues. Thanks & Regards, Rajkumar Raghuwanshi QMG, EnterpriseDB Corporation

Re: parallel append vs. simple UNION ALL

2018-03-16 Thread Ashutosh Bapat
On Wed, Mar 14, 2018 at 2:09 AM, Robert Haas wrote: > On Tue, Mar 13, 2018 at 12:35 AM, Ashutosh Bapat > wrote: >> It looks like it was not changed in all the places. make falied. I >> have fixed all the instances of these two functions in the attached >> patchset (only 0003 changes). Please chec

Re: parallel append vs. simple UNION ALL

2018-03-13 Thread Robert Haas
On Tue, Mar 13, 2018 at 12:35 AM, Ashutosh Bapat wrote: > It looks like it was not changed in all the places. make falied. I > have fixed all the instances of these two functions in the attached > patchset (only 0003 changes). Please check. Oops. Thanks. I'm going to go ahead and commit 0001 he

Re: parallel append vs. simple UNION ALL

2018-03-12 Thread Ashutosh Bapat
On Fri, Mar 9, 2018 at 1:28 AM, Robert Haas wrote: > >> 0003 >> Probably we want to rename generate_union_path() as generate_union_rel() or >> generate_union_paths() since the function doesn't return a path anymore. >> Similarly for generate_nonunion_path(). > > Good point. Changed. It looks lik

Re: parallel append vs. simple UNION ALL

2018-03-08 Thread Robert Haas
On Thu, Mar 1, 2018 at 8:30 AM, Ashutosh Bapat wrote: > The patches look clean. I particularly looked at 0003. > > patch 0001 > +/* > + * Generate partial paths for final_rel, too, if outer query levels might > + * be able to make use of them. > + */ > I am not able to understand t

Re: parallel append vs. simple UNION ALL

2018-03-08 Thread Robert Haas
On Thu, Mar 8, 2018 at 2:46 AM, Rajkumar Raghuwanshi wrote: > On Thu, Mar 8, 2018 at 12:27 AM, Robert Haas wrote: >> >> New patches attached, fixing all 3 of the issues you reported: > > Thanks. new patches applied cleanly on head and fixing all reported issue. Great. Committed 0001. Are you p

Re: parallel append vs. simple UNION ALL

2018-03-07 Thread Rajkumar Raghuwanshi
On Thu, Mar 8, 2018 at 12:27 AM, Robert Haas wrote: > New patches attached, fixing all 3 of the issues you reported: > Thanks. new patches applied cleanly on head and fixing all reported issue. Thanks & Regards, Rajkumar Raghuwanshi QMG, EnterpriseDB Corporation

Re: parallel append vs. simple UNION ALL

2018-03-07 Thread Robert Haas
On Wed, Mar 7, 2018 at 5:36 AM, Rajkumar Raghuwanshi wrote: > With 0001 applied on PG-head, I got reference leak warning and later a > server crash. > this crash is reproducible with enable_parallel_append=off also. > below is the test case to reproduce this. New patches attached, fixing all 3 of

Re: parallel append vs. simple UNION ALL

2018-03-07 Thread Rajkumar Raghuwanshi
Hi, With 0001 applied on PG-head, I got reference leak warning and later a server crash. this crash is reproducible with enable_parallel_append=off also. below is the test case to reproduce this. SET enable_parallel_append=off; SET parallel_setup_cost=0; SET parallel_tuple_cost=0; SET min_paralle

Re: parallel append vs. simple UNION ALL

2018-03-05 Thread Robert Haas
On Tue, Feb 27, 2018 at 6:21 AM, Rajkumar Raghuwanshi wrote: > I have applied 0001 on pg-head, and while playing with regression tests, it > crashed with below test case. > > postgres=# SET min_parallel_table_scan_size=0; > SET > postgres=# SELECT * FROM information_schema.foreign_data_wrapper_opt

Re: parallel append vs. simple UNION ALL

2018-03-01 Thread Ashutosh Bapat
On Sat, Feb 24, 2018 at 2:55 AM, Robert Haas wrote: > > Here's an extended series of patches that now handles both the simple > UNION ALL case (where we flatten it) and the unflattened case: > The patches look clean. I particularly looked at 0003. patch 0001 +/* + * Generate partial pat

Re: parallel append vs. simple UNION ALL

2018-03-01 Thread Rajkumar Raghuwanshi
On Sat, Feb 24, 2018 at 2:55 AM, Robert Haas wrote: > 0004 causes generate_union_path() to consider both the traditional > method and also Gather -> Parallel Append -> [partial path for each > subquery]. This is still a bit rough around the edges and there's a > lot more that could be done here,

Re: parallel append vs. simple UNION ALL

2018-02-28 Thread Amit Khandekar
> On Sat, Feb 24, 2018 at 2:55 AM, Robert Haas wrote: >> >> 0001 is pretty much the same as the subquery-smarts.patch file I >> attached to the previous email. I don't see much reason not to go >> ahead and commit this, although it could use a test case. It makes >> the simple/flattened case wor

Re: parallel append vs. simple UNION ALL

2018-02-27 Thread Rajkumar Raghuwanshi
On Sat, Feb 24, 2018 at 2:55 AM, Robert Haas wrote: > 0001 is pretty much the same as the subquery-smarts.patch file I > attached to the previous email. I don't see much reason not to go > ahead and commit this, although it could use a test case. It makes > the simple/flattened case work. Afte

Re: parallel append vs. simple UNION ALL

2018-02-23 Thread Robert Haas
On Sat, Dec 23, 2017 at 4:53 PM, Robert Haas wrote: > As I mentioned in the commit message for the Parallel Append commit > (ab72716778128fb63d54ac256adf7fe6820a1185), it's kind of sad that this > doesn't work with UNION ALL queries, which are an obvious candidate > for such parallelization. It t

parallel append vs. simple UNION ALL

2017-12-23 Thread Robert Haas
As I mentioned in the commit message for the Parallel Append commit (ab72716778128fb63d54ac256adf7fe6820a1185), it's kind of sad that this doesn't work with UNION ALL queries, which are an obvious candidate for such parallelization. It turns out that it actually does work to a limited degree: assu