Re: parallel append vs. simple UNION ALL

> On Sat, Feb 24, 2018 at 2:55 AM, Robert Haas <robertmhaas(at)gmail(dot)com> 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. After some study I think that the
>> gather-parameter handling is correct, although if somebody felt like
>> reviewing that portion especially I wouldn't say no.

I had a look at 0001 patch. Other than the issue raised by Rajkumar,
it looks good functionally.

Regarding the finalize_plan() changes, I see that in the patch, the
Gather rescan param is now included in the valid_params while calling
finalize_plan() for the SubqueryScan, which looks correct. But I was
thinking that instead of doing that just before the recursive
finalize_plan(), it looks better if we do that at the initial section
of finalize_plan(). We already add initSetParam to valid_params. There
itself we can also add gather_params. Something like this :

@@ -2314,6 +2314,10 @@ finalize_plan(PlannerInfo *root, Plan *plan,
if (initSetParam)
valid_params = bms_union(valid_params, initSetParam);

+ /* Same applies for Gather rescan param */
+ if (gather_param >= 0)
+ valid_params = bms_add_member(valid_params, gather_param);

On 27 February 2018 at 16:51, Rajkumar Raghuwanshi
<rajkumar(dot)raghuwanshi(at)enterprisedb(dot)com> 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_options
> ORDER BY 1, 2, 3;
> server closed the connection unexpectedly
> This probably means the server terminated abnormally
> before or while processing the request.
> The connection to the server was lost. Attempting reset: Failed.

This is happening because there is a ProjectionPath as one of the
subpaths, and that is not parallel safe.

Sort
Sort Key: ((current_database())::information_schema.sql_identifier),
((w.fdwname)::information_schema.sql_identifier),
((((pg_options_to_table(w.fdwoptions))).option_name)::information_schema.sql_identifier)
-> Result
-> ProjectSet
-> Hash Join
Hash Cond: (w.fdwowner = u.oid)
-> Seq Scan on pg_foreign_data_wrapper w
Filter: (pg_has_role(fdwowner,
'USAGE'::text) OR has_foreign_data_wrapper_privilege(oid,
'USAGE'::text))
-> Hash
-> Seq Scan on pg_authid u

In grouping_planner() where partial paths are generated for final_rel,
we can skip non-parallel-safe paths.

--
Thanks,
-Amit Khandekar
EnterpriseDB Corporation
The Postgres Database Company