RE: Parallel INSERT (INTO ... SELECT ...) - Mailing list pgsql-hackers
| From | Tang, Haiying |
|---|---|
| Subject | RE: Parallel INSERT (INTO ... SELECT ...) |
| Date | |
| Msg-id | 2cf243f1ad7f4b808574c78840790f9d@G08CNEXMBPEKD05.g08.fujitsu.local 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 ...)
Re: Parallel INSERT (INTO ... SELECT ...) |
| List | pgsql-hackers |
> 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.)
| patched | master | %reg
|
-----------|------------------|--------------------|--------------------|-------------------|---------------------|-----------------|
partitions |Execution Time(ms)| Planning Time(ms) | Execution Time(ms) | Planning Time(ms) | %reg(Excution Time) |
%reg(alltime) |
-----------|------------------|--------------------|--------------------|-------------------|---------------------|-----------------|
100 | 5.294 | 1.581 | 6.951 | 0.037 | -24% | -2%
|
200 | 9.666 | 3.068 | 13.681 | 0.043 | -29% | -7%
|
500 | 22.742 | 12.061 | 35.928 | 0.125 | -37% | -3%
|
1000 | 46.386 | 24.872 | 75.523 | 0.142 | -39% | -6%
|
I did another test which made check overhead obvious. this case is not fitting for partition purpose, but I put it here
asan extreme case too.
Select table total rows are 1,000, # of partitions is 2000. So only the first 1000 partitions have 1 row per partition,
thelast 1000 partitions have no data inserted.
| patched | master | %reg
|
-----------|------------------|--------------------|--------------------|-------------------|---------------------|-----------------|
partitions |Execution Time(ms)| Planning Time(ms) | Execution Time(ms) | Planning Time(ms) | %reg(Excution Time) |
%reg(alltime) |
-----------|------------------|--------------------|--------------------|-------------------|---------------------|-----------------|
2000 | 45.758 | 51.697 | 80.272 | 0.136 | -43 | 21%
|
Regards,
Tang
pgsql-hackers by date: