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

On Wed, Feb 10, 2021 at 11:13 AM tsunakawa(dot)takay(at)fujitsu(dot)com
<tsunakawa(dot)takay(at)fujitsu(dot)com> wrote:
>
>
> 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.
>
>

I think we might mitigate such losses with a different patch where we
can do a bulk insert for Insert .. Select something like we are
discussing in the other thread [1]. I wonder if these performance
characteristics are due to the reason of underlying bitmap heap scan.
What are the results if disable the bitmap heap scan(Set
enable_bitmapscan = off)? If that happens to be true, then we might
also want to consider if in some way we can teach parallel insert to
cost more in such cases. Another thing we can try is to integrate a
parallel-insert patch with the patch on another thread [1] and see if
that makes any difference but not sure if we want to go there at this
stage unless it is simple to try that out?

[1] - https://www.postgresql.org/message-id/20200508072545.GA9701%40telsasoft.com

--
With Regards,
Amit Kapila.