On Fri, 7 Aug 2020 at 00:44, David Rowley wrote:
> Just coming back to this. I'd like to push it soon, but it's currently
> late here. I'll look at pushing it in my morning in about 8 hours
> time.
Pushed.
David
On Wed, 5 Aug 2020 at 17:25, David Rowley wrote:
>
> On Wed, 5 Aug 2020 at 14:27, David Rowley wrote:
> > So maybe Hash Agg should be doing something similar. Additionally,
> > maybe it should not show the leader details if the leader didn't help.
>
> Here's what I had in mind.
Just coming back
On Wed, 5 Aug 2020 at 14:27, David Rowley wrote:
>
> On Wed, 5 Aug 2020 at 14:13, Justin Pryzby wrote:
> > Also odd (to me). If I encourage more workers, there are "slots" for each
> > "planned" worker, even though fewer were launched:
>
> Looking at explain.c for "num_workers; " (including the
On Wed, 5 Aug 2020 at 14:13, Justin Pryzby wrote:
> Also odd (to me). If I encourage more workers, there are "slots" for each
> "planned" worker, even though fewer were launched:
Looking at explain.c for "num_workers; " (including the final space at
the end), looking at each for loop that loops
On Wed, Aug 05, 2020 at 01:44:17PM +1200, David Rowley wrote:
> On Wed, 5 Aug 2020 at 13:21, Justin Pryzby wrote:
> >
> > I'm testing with a customer's data on pg13dev and got output for which Peak
> > Memory doesn't look right/useful. I reproduced it on 565f16902.
>
> Likely the sanity of those
On Tue, Aug 4, 2020 at 9:44 PM David Rowley wrote:
>
> On Wed, 5 Aug 2020 at 13:21, Justin Pryzby wrote:
> >
> > I'm testing with a customer's data on pg13dev and got output for which Peak
> > Memory doesn't look right/useful. I reproduced it on 565f16902.
>
> Likely the sanity of those results
On Wed, 5 Aug 2020 at 13:21, Justin Pryzby wrote:
>
> I'm testing with a customer's data on pg13dev and got output for which Peak
> Memory doesn't look right/useful. I reproduced it on 565f16902.
Likely the sanity of those results depends on whether you think that
the Memory Usage reported outsi
