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

From Amit Kapila
Subject Re: Parallel INSERT (INTO ... SELECT ...)
Date
Msg-id CAA4eK1JZu=L4wg3GF1T50ame6c9-6W0Gj1eNQFwh9rmsEjqrGQ@mail.gmail.com
Whole thread Raw
In response to RE: Parallel INSERT (INTO ... SELECT ...)  ("Tang, Haiying" <tanghy.fnst@cn.fujitsu.com>)
Responses RE: Parallel INSERT (INTO ... SELECT ...)  ("Tang, Haiying" <tanghy.fnst@cn.fujitsu.com>)
List pgsql-hackers
On Mon, Jan 18, 2021 at 1:02 PM Tang, Haiying
<tanghy.fnst@cn.fujitsu.com> wrote:
>
> > From: Amit Kapila <amit.kapila16@gmail.com>
> > > Can we test cases when we have few rows in the Select table (say
> > > 1000) and there 500 or 1000 partitions. In that case, we won't
> > > select parallelism but we have to pay the price of checking
> > > parallel-safety of all partitions. Can you check this with 100, 200,
> > > 500, 1000 partitions table?
> >
> > I also wanted to see such an extreme(?) case.  The 1,000 rows is not
> > the count per partition but the total count of all partitions.e.g.,
> > when # of partitions is 100, # of rows per partition is 10.
>
> Below results are in serial plan which select table total rows are 1,000. The Excution Time + Planning Time is still
lessthan unpatched.
 
> (does this patch make some optimizes in serial insert? I'm a little confused here, Because the patched execution time
isless than unpatched, but I didn't find information in commit messages about it. If I missed something, please kindly
letme know.)
 
>

I don't think the patch should have any impact on the serial case. I
think you can try to repeat each test 3 times both with and without a
patch and take the median of the three.

-- 
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: "tsunakawa.takay@fujitsu.com"
Date:
Subject: RE: Parallel INSERT (INTO ... SELECT ...)
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: Wrong usage of RelationNeedsWAL