Re: [PERFORM] Query much slower after upgrade to 9.6.1

> > 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

Re: [PERFORM] Query much slower after upgrade to 9.6.1

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).

Re: [PERFORM] Query much slower after upgrade to 9.6.1

> > 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

Re: [PERFORM] Query much slower after upgrade to 9.6.1

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

Re: [PERFORM] Query much slower after upgrade to 9.6.1

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: