RE: Parallel Inserts in CREATE TABLE AS - Mailing list pgsql-hackers

From Hou, Zhijie
Subject RE: Parallel Inserts in CREATE TABLE AS
Date
Msg-id b86351d00dfd4e7d89a3877a9fd3daf1@G08CNEXMBPEKD05.g08.fujitsu.local
Whole thread Raw
In response to Re: Parallel Inserts in CREATE TABLE AS  (Luc Vlaming <luc@swarm64.com>)
Responses Re: Parallel Inserts in CREATE TABLE AS  (Luc Vlaming <luc@swarm64.com>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: poc - possibility to write window function in PL languages
Next
From: Dilip Kumar
Date:
Subject: Re: [HACKERS] Custom compression methods