RE: Determine parallel-safety of partition relations for Inserts
| От | tsunakawa.takay@fujitsu.com |
|---|---|
| Тема | RE: Determine parallel-safety of partition relations for Inserts |
| Дата | |
| Msg-id | TYAPR01MB29908867ED6ECC89B1BC0C4DFEA70@TYAPR01MB2990.jpnprd01.prod.outlook.com обсуждение исходный текст |
| Ответ на | Re: Determine parallel-safety of partition relations for Inserts (Amit Langote <amitlangote09@gmail.com>) |
| Список | pgsql-hackers |
From: Amit Langote <amitlangote09@gmail.com> > Sorry, I haven't looked at the linked threads and the latest patches > there closely enough yet, so I may be misreading this, but if the > inserts will always be done by the leader backend as you say, then why > does the planner need to be checking the parallel safety of the > *target* table's expressions? Yeah, I also wanted to confirm this next - that is, whether the current patch allows the SELECT operation to execute in parallelbut the INSERT operation serially. Oracle allows it; it even allows the user to specify a hint after INSERT andSELECT separately. Even if INSERT in INSERT SELECT can't be run in parallel, it is useful for producing summary data,such as aggregating large amounts of IoT sensor data in parallel and inserting the small amount of summary data serially. Regards Takayuki Tsunakawa
В списке pgsql-hackers по дате отправления: