From: Amit Langote <amitlangot...@gmail.com> > On Wed, Feb 10, 2021 at 1:35 PM Greg Nancarrow <gregn4...@gmail.com> > wrote: > > There's no "second-guessing" involved here. > > There is no underlying way of dividing up the VALUES data of > > "INSERT...VALUES" amongst the parallel workers, even if the planner > > was updated to produce a parallel-plan for the "INSERT...VALUES" case > > (apart from the fact that spawning off parallel workers to insert that > > data would almost always result in worse performance than a > > non-parallel plan...) > > The division of work for parallel workers is part of the table AM > > (scan) implementation, which is not invoked for "INSERT...VALUES". > > I don't disagree that the planner would not normally assign a parallel > path simply to pull values out of a VALUES list mentioned in the > INSERT command, but deciding something based on the certainty of it in > an earlier planning phase seems odd to me. Maybe that's just me > though.
In terms of competitiveness, Oracle does not run INSERT VALUES in parallel: https://docs.oracle.com/en/database/oracle/oracle-database/21/vldbg/types-parallelism.html#GUID-6626C70C-876C-47A4-8C01-9B66574062D8 "The INSERT VALUES statement is never executed in parallel." And SQL Server doesn't either: https://docs.microsoft.com/en-us/sql/relational-databases/query-processing-architecture-guide?view=sql-server-ver15 "Starting with SQL Server 2016 (13.x) and database compatibility level 130, the INSERT … SELECT statement can be executed in parallel when inserting into heaps or clustered columnstore indexes (CCI), and using the TABLOCK hint." Regards Takayuki Tsunakawa
