Skip site navigation (1) Skip section navigation (2)

Re: BUG #5608: array_agg() consumes too much memory

From: Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com>
To: Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-bugs(at)postgresql(dot)org, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: BUG #5608: array_agg() consumes too much memory
Date: 2010-08-14 04:50:58
Message-ID: AANLkTi=eSLVAu0ZeuO9fBxiA1L0Z6RL24pPV6YMbdZ7D@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-hackers
2010/8/14 Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>:
> 2010/8/10 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>> Eventually it might be nice to have some sort of way to specify the
>> estimate to use for any aggregate function --- but for a near-term
>> fix maybe we should just hard-wire a special case for array_agg in
>> count_agg_clauses_walker().
>
> The attached patch is the near-term fix; it adds ALLOCSET_DEFAULT_INITSIZE
> bytes to memory assumption.
>
> We might need the same adjustment for string_agg(), that consumes
> 1024 bytes for the transit condition. array_agg() and string_agg()
> are only aggregates that have "internal" for aggtranstype.

So, is it better to generalize as it adds ALLOCSET_DEFAULT_INITSIZE if
the transtype is internal, rather than specifying individual function
OID as the patch stands?

Regards,

-- 
Hitoshi Harada

In response to

Responses

pgsql-hackers by date

Next:From: Boszormenyi ZoltanDate: 2010-08-14 06:40:24
Subject: Re: WIP partial replication patch
Previous:From: Tom LaneDate: 2010-08-14 03:37:56
Subject: Re: Re: [COMMITTERS] pgsql: Recognize functional dependency on primary keys.

pgsql-bugs by date

Next:From: Stefan KaltenbrunnerDate: 2010-08-14 08:19:01
Subject: Re: BUG #5620: PostgreSQL won't accept the word "user" as a valid column name
Previous:From: Itagaki TakahiroDate: 2010-08-14 02:36:11
Subject: Re: BUG #5608: array_agg() consumes too much memory

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group