Tom Lane wrote:
> "Chris Spotts" <rfusca@gmail.com> writes:
>
>>> many groups are you expecting in that query? Does the plan for the
>>> array_agg query show hash or group aggregation?
>>>
>
>
>> GroupAggregate
>>
>
> Huh, there's no reason it should take much memory then. Maybe you've
> found a memory leak. Can you put together a self-contained test case?
>
> regards, tom lane
>
What do you want specifically as far as details for the test case? I
exported just the table that that was reading from. Installed a new
clean virtual machine ubuntu (jaunty) and then installed 8.4.0.
Imported the table and definition. Ran the same query and the same
thing happened.
Table its selecting from is:
Table "public.trip_ids_to_customer_upload_ids"
Column | Type | Modifiers | Storage | Description
--------------------+---------+-----------+---------+-------------
trip_id | bigint | | plain |
customer_upload_id | integer | | plain |
Indexes:
"trips_customer_id" btree (trip_id, customer_upload_id)
Has OIDs: no
There is 3801347 rows in the table. There are 3773039 distinct trip_id
values. So you can see that the vast majority of rows here are just a
single element array.
