Horton

Re: Memory Accounting

Tomas Vondra <tomas.vondra@2ndquadrant.com>

View thread View on postgr.es
From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Jeff Davis <pgsql@j-davis.com>, Melanie Plageman <melanieplageman@gmail.com>, Soumyadeep Chakraborty <sochakraborty@pivotal.io>, Robert Haas <robertmhaas@gmail.com>, Pg Hackers <pgsql-hackers@postgresql.org>, soumyadeep2007@gmail.com
Date: 2019-10-04T14:29:03Z
Lists: pgsql-hackers 
On Fri, Oct 04, 2019 at 10:26:44AM +0200, Tomas Vondra wrote:
>On Fri, Oct 04, 2019 at 12:36:01AM -0400, Tom Lane wrote:
>>I haven't chased down exactly what else would need to change.
>>It might be that s/int64/Size/g throughout the patch is
>>sufficient, but I haven't analyzed it.
>>
>
>I think so too, but I'll take a closer look in the afternoon, unless you
>beat me to it.
>

I've pushed a fix changing the type to Size, splitting the mem_allocated
to two separate updates (to prevent any underflows in the subtraction).
Hopefully this fixes the 32-bit machines ...

regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Commits

  1. Change MemoryContextMemAllocated to return Size

  2. Use Size instead of int64 to track allocated memory

  3. Add transparent block-level memory accounting

  4. Change the way pre-reading in external sort's merge phase works.

  5. Improve memory management for external sorts.

  6. In array_agg(), don't create a new context for every group.