On Wed, Sep 30, 2020 at 7:38 AM Greg Nancarrow <gregn4...@gmail.com> wrote: > > > > > > > I think you still need to work on the costing part, basically if we > > > are parallelizing whole insert then plan is like below > > > > > > -> Gather > > > -> Parallel Insert > > > -> Parallel Seq Scan > > > > > > That means the tuple we are selecting via scan are not sent back to > > > the gather node, so in cost_gather we need to see if it is for the > > > INSERT then there is no row transferred through the parallel queue > > > that mean we need not to pay any parallel tuple cost. > > > > I just looked into the parallel CTAS[1] patch for the same thing, and > > I can see in that patch it is being handled. > > > > [1] > > https://www.postgresql.org/message-id/CALj2ACWFq6Z4_jd9RPByURB8-Y8wccQWzLf%2B0-Jg%2BKYT7ZO-Ug%40mail.gmail.com > > > > Hi Dilip, > > You're right, the costing for Parallel Insert is not done and > finished, I'm still working on the costing, and haven't posted an > updated patch for it yet.
Okay. > As far as cost_gather() method is concerned, for Parallel INSERT, it > can probably use the same costing approach as the CTAS patch except in > the case of a specified RETURNING clause. Yeah right. I did not think about the returning part. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
