On Sat, Dec 2, 2017 at 4:08 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Fri, Dec 1, 2017 at 7:41 AM, Ashutosh Bapat > <ashutosh.ba...@enterprisedb.com> wrote: >> This code creates plans where there are multiple Gather nodes under an Append >> node. > > We should avoid that. Starting and stopping workers is inefficient, > and precludes things like turning the Append into a Parallel Append.
Ah, I didn't think about it. Thanks for bringing it up. > >> AFAIU, the workers assigned to one gather node can be reused until that >> Gather node finishes. Having multiple Gather nodes under an Append mean that >> every worker will be idle from the time that worker finishes the work till >> the >> last worker finishes the work. > > No, workers will exit as soon as they finish. They don't hang around idle. Sorry, I think I used wrong word "idle". I meant that if a worker finishes and exists, the query can't use it that worker slot until the next Gather node starts. But as you pointed out, starting and stopping a worker is costlier than the cost of not using the slot. So we should avoid such plans. > >> index b422050..1941468 100644 >> --- a/src/tools/pgindent/typedefs.list >> +++ b/src/tools/pgindent/typedefs.list >> @@ -2345,6 +2345,7 @@ UnlistenStmt >> UnresolvedTup >> UnresolvedTupData >> UpdateStmt >> +UpperPathExtraData >> UpperRelationKind >> UpperUniquePath >> UserAuth >> >> Do we commit this file as part of the feature? > > Andres and I regularly commit such changes; Tom rejects them. > We will leave it to the committer to decide what to do with this hunk. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company
