On Tue, Jun 23, 2020 at 12:55 AM Maciek Sakrejda <m.sakre...@gmail.com> wrote: > > Hello, > > I had some questions about the behavior of some accounting in parallel > EXPLAIN plans. Take the following plan: > > ``` > Gather (cost=1000.43..750173.74 rows=2 width=235) (actual > time=1665.122..1665.122 rows=0 loops=1) > Workers Planned: 2 > Workers Launched: 2 > Buffers: shared hit=27683 read=239573 > I/O Timings: read=687.358 > -> Nested Loop (cost=0.43..749173.54 rows=1 width=235) (actual > time=1660.095..1660.095 rows=0 loops=3) > Inner Unique: true > Buffers: shared hit=77579 read=657847 > I/O Timings: read=2090.189 .. > ``` > > The Nested Loop here aggregates data for metrics like `buffers read` > from its workers, and to calculate a metric like `buffers read` for > the parallel leader, we can subtract the values recorded in each > individual worker. This happens in the Seq Scan and Index Scan > children, as well. However, the Gather node appears to only include > values from its direct parallel leader child (excluding that child's > workers). > > This leads to the odd situation that the Gather has lower values for > some of these metrics than its child (because the child node reporting > includes the worker metrics) even though the values are supposed to be > cumulative. >
I don't think this is an odd situation because in this case, child nodes like "Nested Loop" and "Parallel Seq Scan" has a value of 'loops' as 3. So, to get the correct stats at those nodes, you need to divide it by 3 whereas, at Gather node, the value of 'loops' is 1. If you want to verify this thing then try with a plan where loops should be 1 for child nodes as well, you should get the same value at both Gather and Parallel Seq Scan nodes. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
