> On Sat, Feb 24, 2018 at 2:55 AM, Robert Haas <robertmh...@gmail.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.raghuwan...@enterprisedb.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

Reply via email to