On Fri, Dec 29, 2017 at 2:21 AM, Thomas Munro <thomas.mu...@enterprisedb.com> wrote: > On Thu, Dec 28, 2017 at 5:15 PM, Thomas Munro > <thomas.mu...@enterprisedb.com> wrote: >> On Thu, Dec 28, 2017 at 3:32 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> ! Buckets: 1024 (originally 2048) Batches: 1 >>> (originally 1) Memory Usage: 0kB >>> ! Execution time: 243.120 ms >>> >>> I don't have enough insight to be totally sure what this means, but the >>> "Memory Usage: 0kB" bit is obviously bogus, so I'd venture that at least >>> part of the issue is failure to return stats from a worker. >> >> Hmm. Yeah, that seems quite likely -- thanks. Investigating now. > > This is explained by the early exit case in > ExecParallelHashEnsureBatchAccessors(). With just the right timing, > it finishes up not reporting the true nbatch number, and never calling > ExecParallelHashUpdateSpacePeak().
Hi Tom, You mentioned that prairiedog sees the problem about one time in thirty. Would you mind checking if it goes away with this patch applied? -- Thomas Munro http://www.enterprisedb.com
fix-phj-explain.patch
Description: Binary data
