On Mon, Dec 7, 2020 at 7:04 PM Bharath Rupireddy <bharath.rupireddyforpostg...@gmail.com> wrote: > > I'm not quite sure how to address this. Can we not allow the planner > to consider that the select is for CTAS and check only after the > planning is done for the Gather node and other checks? >
IIUC, you are saying that we should not influence the cost of gather node even when the insertion would be done by workers? I think that should be our fallback option anyway but that might miss some paths to be considered parallel where the cost becomes more due to parallel_tuple_cost (aka tuple transfer cost). I think the idea is we can avoid the tuple transfer cost only when Gather is the top node because only at that time we can push insertion down, right? How about if we have some way to detect the same before calling generate_useful_gather_paths()? I think when we are calling apply_scanjoin_target_to_paths() in grouping_planner(), if the query_level is 1, it is for CTAS, and it doesn't have a chance to create UPPER_REL (doesn't have grouping, order, limit, etc clause) then we can probably assume that the Gather will be top_node. I am not sure about this but I think it is worth exploring. -- With Regards, Amit Kapila.