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

From tsunakawa.takay@fujitsu.com
Subject RE: Parallel INSERT (INTO ... SELECT ...)
Date
Msg-id TYAPR01MB2990825902E70EC37D945479FE8D9@TYAPR01MB2990.jpnprd01.prod.outlook.com
Whole thread Raw
In response to RE: Parallel INSERT (INTO ... SELECT ...)  ("Hou, Zhijie" <houzj.fnst@cn.fujitsu.com>)
Responses RE: Parallel INSERT (INTO ... SELECT ...)  ("Hou, Zhijie" <houzj.fnst@cn.fujitsu.com>)
List pgsql-hackers
From: Hou, Zhijie/侯 志杰 <houzj.fnst@cn.fujitsu.com>
> Till now, what I found is that:
> With tang's conf, when doing parallel insert, the walrecord is more than serial
> insert (IMO, this is the main reason why it has performance degradation) See
> the attatchment for the plan info.
> 
> I have tried alter the target table to unlogged and then the performance
> degradation will not happen any more.
> 
> And the additional walrecord seems related to the index on the target table.
> If the target table does not have any index, the wal record is the same between
> parallel plan and serial plan.
> Also, it does not have performance degradation without index.


[serial]
 Insert on public.testscan  (cost=3272.20..3652841.26 rows=0 width=0) (actual time=360.474..360.476 rows=0 loops=1)
   Buffers: shared hit=392569 read=3 dirtied=934 written=933
   WAL: records=260354 bytes=16259841

[parallel]
   ->  Insert on public.testscan  (cost=3272.20..1260119.35 rows=0 width=0) (actual time=378.227..378.229 rows=0
loops=5)
         Buffers: shared hit=407094 read=4 dirtied=1085 written=1158
         WAL: records=260498 bytes=17019359


More pages are dirtied and written in the parallel execution.  Aren't the index and possibly the target table bigger
withparallel execution than with serial execution?  That may be due to the difference of inserts of index keys.
 


Regards
Takayuki Tsunakawa



pgsql-hackers by date:

Previous
From: "Euler Taveira"
Date:
Subject: Re: Clean up code
Next
From: Fujii Masao
Date:
Subject: Re: adding wait_start column to pg_locks