>
> Did you pay attention to the estimated number of groups (ie, estimated
> output rowcount for the aggregation plan node) while fooling around with
> the statistics? How does it compare to reality, and to 9.5's estimate?
>
I'm re-doing the tests and paying attention to that now.
With statistic
Adam Brusselback writes:
>> If the problem is "new server won't use hashagg", I'd wonder whether
>> the work_mem setting is the same, or whether maybe you need to bump
>> it up some (the planner's estimate of how big the hashtable would be
>> might have changed a bit).
> I actually was speaking w
>
> If the problem is "new server won't use hashagg", I'd wonder whether
> the work_mem setting is the same, or whether maybe you need to bump
> it up some (the planner's estimate of how big the hashtable would be
> might have changed a bit).
>
I actually was speaking with Stephen Frost in the slac
Adam Brusselback writes:
> As suggested in the Postgres slack channel by lukasfittl, I disabled
> hashagg on my old server, and ran the query again. That changed one piece
> to a groupagg (like was used on the new server) and the performance was
> similar to the 9.6.1 box.
If the problem is "new
As suggested in the Postgres slack channel by lukasfittl, I disabled
hashagg on my old server, and ran the query again. That changed one piece
to a groupagg (like was used on the new server) and the performance was
similar to the 9.6.1 box.
9.5.5 w/ hashagg disabled: https://explain.depesz.com/s/S
Hello all, I have a query that was running quickly enough on 9.5.5 and has
slowed to a halt after upgrading to 9.6.1.
The server hardware is the same, 2 core, 4GB ram DigitalOcean virtual
server, running Debian 8.6.
The query is a pretty heavy reporting query to aggregate the dollar value
of "cla
