Re: Parallel INSERT (INTO ... SELECT ...)

From: Greg Nancarrow <gregn4422(at)gmail(dot)com>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Parallel INSERT (INTO ... SELECT ...)
Date: 2020-10-12 05:34:21
Message-ID: CAJcOf-fr37JxktSMrHOieuCaxRVrFGKX-o6-y0ejwRXy7h3GHg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Oct 12, 2020 at 2:11 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
>
> On Mon, Oct 12, 2020 at 3:42 PM Greg Nancarrow <gregn4422(at)gmail(dot)com> wrote:
> > On Sun, Oct 11, 2020 at 1:39 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> > > pathnode->path.total_cost += subpath->total_cost;
> > > - pathnode->path.rows += subpath->rows;
> > > + if (returningLists != NIL)
> > > + pathnode->path.rows += subpath->rows;
> > > total_size += subpath->pathtarget->width * subpath->rows;
> > > }
>
> Erm, except the condition should of course cover total_size too.
>
> > Agree, thanks (bug in existing Postgres code, right?)
>
> Yeah, I think we should go ahead and fix that up front. Here's a
> version with a commit message.

I've checked it and tested it, and it looks fine to me.
Also, it seems to align with the gripe in the old comment about width
("XXX this is totally wrong: we should report zero if no RETURNING
...").
I'm happy for you to commit it.

Regards,
Greg Nancarrow
Fujitsu Australia

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2020-10-12 05:43:06 Re: speed up unicode normalization quick check
Previous Message Masahiko Sawada 2020-10-12 05:29:01 Re: Resetting spilled txn statistics in pg_stat_replication