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 only create 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
