Tom Lane wrote:
"Chris Spotts" <rfu...@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.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
