Re: Is Hash Agg being used? 7.4 seems to handle this query worse than 7.3
От | Tom Lane |
---|---|
Тема | Re: Is Hash Agg being used? 7.4 seems to handle this query worse than 7.3 |
Дата | |
Msg-id | 26461.1044983690@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Is Hash Agg being used? 7.4 seems to handle this query worse than 7.3 (Greg Stark <gsstark@mit.edu>) |
Ответы |
Re: Is Hash Agg being used? 7.4 seems to handle this query worse than 7.3
Re: Is Hash Agg being used? 7.4 seems to handle this query worse than 7.3 |
Список | pgsql-general |
Greg Stark <gsstark@mit.edu> writes: > There's only a small decrease in speed from 7.3 to CVS now, but I was hoping > for a big speed increase from hash aggregates since most of the time is being > sunk into that sort. But it definitely isn't using them. I guess TNSTAAFL. It looks like it's avoiding the hash choice because it thinks there will be many groups, 15122 to be exact: > -> GroupAggregate (cost=2686.58..2951.21 rows=15122 width=24) (actual time=917.64..1033.40 rows=31loops=1) You could probably persuade it that hashed aggregation will be okay by increasing sort_mem sufficiently. But it would also be interesting to see if the number-of-groups estimate can be improved ... 15122 is rather badly off from the true value of 31 ... regards, tom lane
В списке pgsql-general по дате отправления: