(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
