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 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. With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
