| От | Greg Stark |
|---|---|
| Тема | Re: Poor performance of group by query |
| Дата | |
| Msg-id | 87pta78r9s.fsf@stark.xeocode.com обсуждение исходный текст |
| Ответ на | Poor performance of group by query ("Jim C. Nasby" <jim@nasby.net>) |
| Список | pgsql-performance |
> stats=# explain analyze SELECT work_units, min(raw_rank) AS rank FROM Trank_work_overall GROUP BY work_units; > > ... > > raw_rank | bigint | > work_units | bigint | If you create a copy of the same table using regular integers does that run fast? And a copy of the table using bigints is still slow like the original? I know bigints are less efficient than integers because they're handled using dynamically allocated memory. This especially bites aggregate functions. But I don't see why it would be any slower for a hash aggregate than a regular aggregate. It's a pretty gross amount of time for 18k records. There was a thought a while back about making 64-bit machines handle 64-bit datatypes like bigints without pointers. That would help on your Opteron. -- greg
В списке pgsql-performance по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера