RE: Parallel INSERT (INTO ... SELECT ...)

From: Hou, Zhijie/侯 志杰 
> Sorry, Maybe the tablename is a little confused,
> but 'testscan_index' is actually a table's name.
...
> Did I miss something ?

No, I don't think so.  I just wanted to know the facts correctly.  Your EXPLAIN output shows that the target table is testscan as follows.  How does testscan_index relate to testscan?

   ->  Insert on public.testscan  (cost=3272.20..1260119.35 rows=0 width=0) (actual time=378.227..378.229 rows=0 loops=5)


> It did have performance gain, but I think it's not huge enough to ignore the
> extra's index cost.
> What do you think ?

Yes... as you suspect, I'm afraid the benefit from parallel bitmap scan may not compensate for the loss of the parallel insert operation.

The loss is probably due to 1) more index page splits, 2) more buffer writes (table and index), and 3) internal locks for things such as relation extension and page content protection.  To investigate 3), we should want something like [1], which tells us the wait event statistics (wait count and time for each wait event) per session or across the instance like Oracke, MySQL and EDB provides.  I want to continue this in the near future.


[1]
Add accumulated statistics for wait event
https://commitfest.postgresql.org/28/2332/


Regards
Takayuki Tsunakawa