On Fri, Nov 13, 2015 at 6:17 PM, Thom Brown <
thom@linux.com> wrote:
>
> >
> > The number of shared buffers hit could be different across different runs
> > because the read sequence of parallel workers can't be guaranteed, also
> > I don't think same is even guaranteed for Seq Scan node, the other
> > operations
> > in parallel could lead to different number, however the actual problem was
> > that in one of the plans shown by you [1], the Buffers hit at Gather node
> > (175288) is lesser than the Buffers hit at Parallel Seq Scan node (241201).
> > Do you still (after applying above patch) see that Gather node is showing
> > lesser hit buffers than Parallel Seq Scan node?
>
> Hmm... that's odd, I'm not seeing the problem now, so maybe I'm mistaken there.
>
Thanks for confirming the same.
> >
> >> or the actual time taken.
> >>
> >
> > Exactly what time you are referring here, Execution Time or actual time
> > shown on Parallel Seq Scan node and what problem do you see with
> > the reported time?
>
> I'm referring to the Parallel Seq Scan actual time, showing
> "379.407..1141.437" with 1 worker, but the total execution time shows
> 403.045. If one worker is taking over a second, how come the whole
> query was less than half a second?
>
Yeah, this could be possible due to the way currently time is accumulated,
see my mail which I sent just before this mail. I think we might need to do
something, else it could be confusing for users.
