From: | Chris Spotts <rfusca(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: array_agg crash? |
Date: | 2009-07-22 06:18:26 |
Message-ID: | 4A66AF32.2090506@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Tom Lane wrote:
> "Chris Spotts" <rfusca(at)gmail(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Phoenix Kiula | 2009-07-22 09:26:37 | Re: Best practices for moving UTF8 databases |
Previous Message | Ow Mun Heng | 2009-07-22 05:53:32 | Re: Row insertion w/ trigger to another table update causes row insertion to _not_ occur |