On Fri, Dec 29, 2017 at 2:21 AM, Thomas Munro
<thomas.munro@enterprisedb.com> wrote:
> On Thu, Dec 28, 2017 at 5:15 PM, Thomas Munro
> <thomas.munro@enterprisedb.com> wrote:
>> On Thu, Dec 28, 2017 at 3:32 PM, Tom Lane <tgl@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
