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

From Amit Kapila
Subject Re: Parallel INSERT (INTO ... SELECT ...)
Date
Msg-id CAA4eK1LVdyXfA=9UTDVtv2zrt5sNJj7LG11QqeqGFrfApo84Xg@mail.gmail.com
Whole thread Raw
In response to RE: Parallel INSERT (INTO ... SELECT ...)  ("tsunakawa.takay@fujitsu.com" <tsunakawa.takay@fujitsu.com>)
Responses RE: Parallel INSERT (INTO ... SELECT ...)
List pgsql-hackers
On Wed, Feb 10, 2021 at 11:13 AM tsunakawa.takay@fujitsu.com
<tsunakawa.takay@fujitsu.com> wrote:
>
>
> 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. 
>
>

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.



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: WIP: WAL prefetch (another approach)
Next
From: Amit Langote
Date:
Subject: Re: Parallel INSERT (INTO ... SELECT ...)