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

Поиск
Список
Период
Сортировка
От tsunakawa.takay@fujitsu.com
Тема RE: Parallel INSERT (INTO ... SELECT ...)
Дата
Msg-id OSBPR01MB29826C3FB3CB38FD5C5CE667FEA40@OSBPR01MB2982.jpnprd01.prod.outlook.com
обсуждение исходный текст
Ответ на RE: Parallel INSERT (INTO ... SELECT ...)  ("Tang, Haiying" <tanghy.fnst@cn.fujitsu.com>)
Ответы RE: Parallel INSERT (INTO ... SELECT ...)  ("Tang, Haiying" <tanghy.fnst@cn.fujitsu.com>)
Список pgsql-hackers
From: Tang, Haiying <tanghy.fnst@cn.fujitsu.com>
> (does this patch make some optimizes in serial insert? I'm a little confused
> here, Because the patched execution time is less than unpatched, but I didn't
> find information in commit messages about it. If I missed something, please
> kindly let me know.)

I haven't thought of anything yet.  Could you show us the output of EXPLAIN (ANALYZE, BUFFERS, VERBOSE) of 1,000
partitionscase for the patched and unpatched?  If it doesn't show any difference, the output of perf may be necessary
next.

(BTW, were all the 1,000 rows stored in the target table?)


> I did another test which made check overhead obvious. this case is not fitting
> for partition purpose, but I put it here as an 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, the last 1000 partitions have no data
> inserted.

Thank you, that's a good test.


Regards
Takayuki Tsunakawa


В списке pgsql-hackers по дате отправления:

Предыдущее
От: japin
Дата:
Сообщение: Re: Narrow the scope of the variable outputstr in logicalrep_write_tuple
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: Parallel INSERT (INTO ... SELECT ...)