(2018/07/04 11:00), Etsuro Fujita wrote:
> (2018/07/04 1:35), Andres Freund wrote:
>> What's the plan forward here?
>
> I still think that this approach would be the right way to go, so I plan
> to polish the patch.
The approach would not require extra cycles where partitioning is not
involved as discussed before, and makes code much simpler, which would
make maintenance and the FDW author's life easy, so I still think that
the approach would be the direction to go in. So, I updated the patch.
Here are changes:
* I assumed that the child plan passed to adjust_subplan_tlist was a
scan or join unless it was Append or MergeAppend, but I noticed I was
wrong; if the topmost scan/join relation is partitioned,
apply_scanjoin_target_to_paths might have pushed down ProjectSet or
Result to each of partitions. So, in that case the child's plan would
have ProjectSet or Result atop the scan or join plan. (I could not
produce such an example, though.) To address this, I modified
build_childrel_tlist so that we just apply adjust_appendrel_attrs to the
parent's targetlist to get the child's if the parent is the topmost
scan/join relation. So, we don't need to care about that in
adjust_subplan_tlist. I think this change would also increase the
efficiency for that case. I added regression test cases for that as well.
* I fixed an oversight in outfuncs.c.
* I renamed member variables I added to RelOptInfo before, and revised
code/comments a bit.
Attached is an updated version of the patch.
Best regards,
Etsuro Fujita