Re: Poor performance of group by query - Mailing list pgsql-performance

From Greg Stark
Subject Re: Poor performance of group by query
Date
Msg-id 87pta78r9s.fsf@stark.xeocode.com
Whole thread Raw
In response to Poor performance of group by query  ("Jim C. Nasby" <jim@nasby.net>)
List 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 by date:

Previous
From: Manfred Koizar
Date:
Subject: Re: query slows down with more accurate stats
Next
From: Tom Lane
Date:
Subject: Re: sunquery and estimated rows