Re: Expression errors with "FOR UPDATE" and postgres_fdw with partition wise join enabled.

(2018/07/02 18:46), Etsuro Fujita wrote:
> (2018/06/22 23:58), Robert Haas wrote:
>> And, in general, it seems to me that we want
>> to produce the right outputs at the lowest possible level of the plan
>> tree. For instance, suppose that one of the relations being scanned
>> is not parallel-safe but the others are. Then, we could end up with a
>> plan like this:
>>
>> Append
>> -> Seq Scan on temp_rela
>> -> Gather
>> -> Parallel Seq Scan on thing1
>> -> Gather
>> -> Parallel Seq Scan on thing2
>>
>> If a projection is required to convert the row type expression, we
>> certainly want that to get pushed below the Gather, not to happen at
>> the Gather level itself.
>
> IIUC, we currently don't consider such a plan for partition-wise join;
> we'll only consider gathering partial paths for the parent appendrel.

While updating the patch, I noticed that I'm wrong here. IIUC,
apply_scanjoin_target_to_paths would allow us to consider such an Append
for a partitioned relation when scanjoin_target_parallel_safe=false, as
it generates new Append paths by recursively adjusting all partitions
for which we call generate_gather_paths in that case as shown below:

/*
* If the scan/join target is not parallel-safe, partial paths cannot
* generate it.
*/
if (!scanjoin_target_parallel_safe)
{
/*
* Since we can't generate the final scan/join target, this is our
* last opportunity to use any partial paths that exist. We
don't do
* this if the case where the target is parallel-safe, since we
will
* be able to generate superior paths by doing it after the final
* scan/join target has been applied.
*
* Note that this may invalidate rel->cheapest_total_path, so
we must
* not rely on it after this point without first calling
set_cheapest.
*/
generate_gather_paths(root, rel, false);

/* Can't use parallel query above this level. */
rel->partial_pathlist = NIL;
rel->consider_parallel = false;
}

I don't produce a test case where the plan is an Append with Gather
subplans, but I'm not sure that it's a good thing to allow us to
consider such a plan because in that plan, each Gather would try to grab
its own pool of workers. Am I missing something?

Best regards,
Etsuro Fujita