Re: Explain buffers wrong counter with parallel plans

On Tue, Jul 3, 2018 at 4:18 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> On Mon, Jul 2, 2018 at 6:02 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>
>
>> To fix the problem with Limit that you mention, we could just modify
>> nodeLimit.c so that when the state is changed from LIMIT_INWINDOW to
>> LIMIT_WINDOWEND, we also call ExecShutdownNode on the child plan.
>>
>
> It should work.
>

I have tried this idea, but it doesn't completely solve the problem.
The problem is that nodes below LIMIT won't get a chance to accumulate
the stats as they won't be able to call InstrStopNode. So the result
will be something like below:

postgres=# explain (analyze,buffers,timing off,costs off) select *
from t1 limit 50000;
QUERY PLAN
-----------------------------------------------------------------
Limit (actual rows=50000 loops=1)
Buffers: shared hit=6 read=224
-> Gather (actual rows=50000 loops=1)
Workers Planned: 2
Workers Launched: 2
Buffers: shared hit=1 read=63
-> Parallel Seq Scan on t1 (actual rows=17213 loops=3)
Buffers: shared hit=6 read=224
Planning Time: 0.105 ms
Execution Time: 1363068.675 ms
(10 rows)

In this plan, you can notice that stats (Buffers:) at Parallel Seq
Scan and Limit are same, but Gather node shows different stats. One
idea could be that in ExecShutdownNode, somehow, we allow the nodes to
count the stats, maybe by calling InstrStartNode/InstrStopNode, but
not sure if that is the best way to fix it.

Thoughts?

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com