On Sat, Apr 30, 2016 at 4:54 AM, David Rowley <david.row...@2ndquadrant.com> wrote: >> Right, but they're probably not doing the SAME work. You can look at >> EXPLAIN (ANALYZE, VERBOSE, BUFFERS) to see. Of course, all the work >> above the Gather node is being done by the leader, but the stuff below >> the Gather node often has a bit of participation from the leader, but >> is mostly the workers. > > Robert, I'd imagine that most of your tests to make you think what you > do would have come from testing parallel seq scan, where perhaps > Daniel's comes from testing something like parallel aggregates, or at > least something that gives the workers a decent amount of work per > tuple returned.
Sure, if you're doing parallel aggregate with a small number of output groups, the work distribution will be much more nearly equal. I wasn't trying to dispute that. There are many cases where it doesn't work out that way, though. > So I'd say this very much depends on how busy the main process is > pulling rows from each worker. Absolutely. > It would also be quite nice if we could see at a glance how much the > main process did, without having to go subtracting what all the > workers managed to do. I agree, but that looked considerably more invasive, because of the way that the worker results get aggregated into the leader's result. There may be a clever way to avoid that, but I didn't see it. Or we may want to do it anyway despite it requiring more invasive changes. I just wasn't in a hurry to rush into all that while trying to get parallel query v1 out the door. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
