On Wed, Jul 15, 2015 at 3:27 AM, Jeff Davis <pgsql@j-davis.com> wrote:
> On Tue, 2015-07-14 at 16:19 -0400, Robert Haas wrote:
>> tuplesort.c does its own accounting, and TBH that seems like the right
>> thing to do here, too. The difficulty is, I think, that some
>> transition functions use an internal data type for the transition
>> state, which might not be a single palloc'd chunk. But since we can't
>> spill those aggregates to disk *anyway*, that doesn't really matter.
>
> So would it be acceptable to just ignore the memory consumed by
> "internal", or come up with some heuristic?
Either one would be OK with me. I'd probably ignore that for the
first version of the patch and just let the hash table grow without
bound in that case. Then in a later patch I'd introduce additional
infrastructure to deal with that part of the problem. But if
something else works out well while coding it up, I'd be OK with that,
too.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
