Re: Expression errors with "FOR UPDATE" and postgres_fdw with partitionwise join enabled.
От | Etsuro Fujita |
---|---|
Тема | Re: Expression errors with "FOR UPDATE" and postgres_fdw with partitionwise join enabled. |
Дата | |
Msg-id | 5B3C9C33.6030203@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: Expression errors with "FOR UPDATE" and postgres_fdw with partitionwise join enabled. (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>) |
Ответы |
Re: Expression errors with "FOR UPDATE" and postgres_fdw withpartition wise join enabled.
|
Список | pgsql-hackers |
(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
В списке pgsql-hackers по дате отправления: