Re: Parallel INSERT (INTO ... SELECT ...)
От | Amit Kapila |
---|---|
Тема | Re: Parallel INSERT (INTO ... SELECT ...) |
Дата | |
Msg-id | CAA4eK1JZu=L4wg3GF1T50ame6c9-6W0Gj1eNQFwh9rmsEjqrGQ@mail.gmail.com обсуждение исходный текст |
Ответ на | RE: Parallel INSERT (INTO ... SELECT ...) ("Tang, Haiying" <tanghy.fnst@cn.fujitsu.com>) |
Ответы |
RE: Parallel INSERT (INTO ... SELECT ...)
|
Список | 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 по дате отправления: