From: Hou, Zhijie/侯 志杰 <houzj.fnst@cn.fujitsu.com>
> 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
testscanas 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
insertoperation.
The loss is probably due to 1) more index page splits, 2) more buffer writes (table and index), and 3) internal locks
forthings 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
instancelike 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
