On Fri, Nov 13, 2015 at 6:17 PM, Thom Brown <t...@linux.com> wrote:
> >
> > The number of shared buffers hit could be different across different
> > 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
> > that in one of the plans shown by you [1], the Buffers hit at Gather
> > (175288) is lesser than the Buffers hit at Parallel Seq Scan node
> > Do you still (after applying above patch) see that Gather node is
> > lesser hit buffers than Parallel Seq Scan node?
> Hmm... that's odd, I'm not seeing the problem now, so maybe I'm mistaken

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.

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

Reply via email to