On Wed, Jul 15, 2015 at 3:27 AM, Jeff Davis <pg...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
