On Mon, Jun 20, 2016 at 3:06 AM, Satoshi Nagayasu <sn...@uptime.jp> wrote: > IMHO, "actual rows" of "Parallel Seq Scan" should not be divided by the loops, > because the total rows processed here is 10000000, not 3333333 * 3. > I think the actual row value shown here "3333333 " is a bit confusing and > tricky > for users.
I don't think the total number of rows for a node should EVER be divided by the number of loops. We've had that behavior for a long time and I find it to be mind-numbingly stupid. Whenever I'm reading an EXPLAIN plan, I end up trying to figure out what's really going on by multiplying the number of rows shown by the loop count, but often the row count is very small, like 0 or 1 or 2, so the round-off error is large and you can't really tell what's happening. Nobody wants to know the average number of rows returned per node execution: they want, as you want here, the total number of rows that node ever processed. I doubt we can convince Tom Lane to let us change it, but feel free to post a patch. One thing I don't think we can do here is have some weird exception where parallel query works differently from everything else. "loops" just counts the number of times that the node was executed. It most often ends up >1 when the plan node is on the inner side of a nested loop, but parallel query ends up creating that scenario also. There's no real way to separate those things out, though. If a node executes 3 times in one worker, 4 times in another, and once in the leader, what value are you going to display for loops other than 8? And if you accept that's the right answer in that case, then you pretty much need the answer when it executes once in one worker, once in another worker, and once in the leader to be 3. I agree that this is very confusing - and you're not the first person to complain about it - but I think that parallel query is merely throwing light on the fact that the pre-existing behavior of EXPLAIN is poorly chosen, not creating any fundamentally new issue. -- 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
