RE: Parallel INSERT (INTO ... SELECT ...) - Mailing list pgsql-hackers

From tsunakawa.takay@fujitsu.com
Subject RE: Parallel INSERT (INTO ... SELECT ...)
Date
Msg-id OSBPR01MB29826C3FB3CB38FD5C5CE667FEA40@OSBPR01MB2982.jpnprd01.prod.outlook.com
Whole thread Raw
In response to RE: Parallel INSERT (INTO ... SELECT ...)  ("Tang, Haiying" <tanghy.fnst@cn.fujitsu.com>)
Responses RE: Parallel INSERT (INTO ... SELECT ...)  ("Tang, Haiying" <tanghy.fnst@cn.fujitsu.com>)
List pgsql-hackers
From: Tang, Haiying <tanghy.fnst@cn.fujitsu.com>
> (does this patch make some optimizes in serial insert? I'm a little confused
> here, Because the patched execution time is less than unpatched, but I didn't
> find information in commit messages about it. If I missed something, please
> kindly let me know.)

I haven't thought of anything yet.  Could you show us the output of EXPLAIN (ANALYZE, BUFFERS, VERBOSE) of 1,000
partitionscase for the patched and unpatched?  If it doesn't show any difference, the output of perf may be necessary
next.

(BTW, were all the 1,000 rows stored in the target table?)


> I did another test which made check overhead obvious. this case is not fitting
> for partition purpose, but I put it here as an extreme case too.
> Select table total rows are 1,000, # of partitions is 2000. So only the first 1000
> partitions have 1 row per partition, the last 1000 partitions have no data
> inserted.

Thank you, that's a good test.


Regards
Takayuki Tsunakawa


pgsql-hackers by date:

Previous
From: japin
Date:
Subject: Re: Narrow the scope of the variable outputstr in logicalrep_write_tuple
Next
From: Amit Kapila
Date:
Subject: Re: Parallel INSERT (INTO ... SELECT ...)