On Thu, 17 Jan 2019 at 00:31, David Conlin <dc345@xxxxxxxxxx> wrote: > How the time values combine with parallelism. For example, each execution of the sort node takes an average of 48.5s, over three loops. This makes a total running time of 145.5s. Even if this was perfectly distributed between the two workers, I would expect this to take 72.75s, which is more than the total execution time, so it can't take this long. > How the row numbers combine with those in the "Workers" subkey. For example, in the Sort node, worker #0 produces 3,277,980 rows, while worker #1 produces 3,385,130 rows. The Sort node as a whole produces 3,333,337 rows per loop, for a total of 10,000,010 (the value in the gather merge node). I would have expected the number of rows produced by the two workers to sum to the number produced by the Sort node as a whole, either per loop or in total. > How the "Actual Loops" values combine with those in the "Workers" subkey. For example, the "Sort" node has 3 loops, but each of the workers inside it have 1 loop. I would have expected either: > > each of the workers to have done 3 loops (since the sort is executed 3 times), or > the number of loops in the two workers to sum to three (if the three executions of the sort are distributed across the two workers) It's important to know that all of the actual row counts and actual time are divided by the number of loops, which in this case is 3, one per process working on that part of the plan. There are two workers, but also the main process helps out too. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
