On 04-01-2021 12:16, Hou, Zhijie wrote:
> Hi
>
>> ================
>> wrt v18-0002....patch:
>>
>> It looks like this introduces a state machine that goes like:
>> - starts at CTAS_PARALLEL_INS_UNDEF
>> - possibly moves to CTAS_PARALLEL_INS_SELECT
>> - CTAS_PARALLEL_INS_TUP_COST_CAN_IGN can be added
>> - if both were added at some stage, we can go to
>> CTAS_PARALLEL_INS_TUP_COST_IGNORED and ignore the costs
>>
>> what i'm wondering is why you opted to put logic around
>> generate_useful_gather_paths and in cost_gather when to me it seems more
>> logical to put it in create_gather_path? i'm probably missing something
>> there?
>
> IMO, The reason is we want to make sure we only ignore the cost when Gather is the top node.
> And it seems the generate_useful_gather_paths called in apply_scanjoin_target_to_paths is the right place which can
onlycreate top node Gather.
> So we change the flag in apply_scanjoin_target_to_paths around generate_useful_gather_paths to identify the top
node.
>
>
> Best regards,
> houzj
>
>
Hi,
I was wondering actually if we need the state machine. Reason is that as
AFAICS the code could be placed in create_gather_path, where you can
also check if it is a top gather node, whether the dest receiver is the
right type, etc? To me that seems like a nicer solution as its makes
that all logic that decides whether or not a parallel CTAS is valid is
in a single place instead of distributed over various places.
Kind regards,
Luc
