On Mon, Oct 5, 2020 at 10:36 PM Dilip Kumar <dilipbal...@gmail.com> wrote: > > > > I have one question which is common to both this patch and parallel > > > inserts in CTAS[1], do we need to skip creating tuple > > > queues(ExecParallelSetupTupleQueues) as we don't have any tuples > > > that's being shared from workers to leader? > > > > > > > As far as this patch is concerned we might need to return tuples when > > there is a Returning clause. I think for the cases where we don't need > > to return tuples we might want to skip creating these queues if it is > > feasible without too many changes. >
Hi Dilip, You're right. I've included that in my latest version of the patch (so Gather should only start tuple queues in the case of parallel SELECT or parallel INSERT with a RETURNING clause). Other functionality updated includes: - Added more necessary exclusions for Parallel INSERT INTO ... SELECT ... (but allowing underlying query to still be parallel): - non-parallel-safe triggers - non-parallel-safe default and check expressions - foreign tables - temporary tables - Added support for before/after statement-level INSERT triggers (can't allow parallel workers to execute these) - Adjusted cost of Gather node, for when RETURNING clause is not specified I have not found issues with partition tables (yet) or toast column values. Also, I have attached a separate patch (requested by Andres Freund) that just allows the underlying SELECT part of "INSERT INTO ... SELECT ..." to be parallel. Regards, Greg Nancarrow Fujitsu Australia
0004-ParallelInsertSelect.patch
Description: Binary data
0001-InsertParallelSelect.patch
Description: Binary data
