On Wed, Sep 23, 2020 at 2:21 PM Greg Nancarrow <gregn4...@gmail.com> wrote: > > > - When INSERTs are made parallel, currently the reported row-count in > > the "INSERT 0 <row-count>" status only reflects the rows that the > > leader has processed (not the workers) - so it is obviously less than > > the actual number of rows inserted. > > Attached an updated patch which fixes this issue (for parallel > INSERTs, each worker's processed tuple count is communicated in shared > memory back to the leader, where it is added to the global > "es_processed" count).
I noticed that we are not having any check for skipping temporary table insertion. /* Check if the target relation has foreign keys; if so, avoid * creating a parallel Insert plan (because inserting into * such tables would result in creation of new CommandIds, and * this isn't supported by parallel workers). * Similarly, avoid creating a parallel Insert plan if ON * CONFLICT ... DO UPDATE ... has been specified, because * parallel UPDATE is not supported. * However, do allow any underlying query to be run by parallel * workers in these cases. */ You should also include temporary tables check here, as parallel workers might not have access to temporary tables. Regards, Vignesh EnterpriseDB: http://www.enterprisedb.com