Re: Memory Accounting v11

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Memory Accounting v11
Date: 2015-06-15 02:12:49
Message-ID: 1434334369.4369.53.camel@jeff-desktop
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, 2015-06-14 at 16:21 -0400, Tom Lane wrote:
> Meh. HashAgg could track its memory usage without loading the entire
> system with a penalty.

When I tried doing it outside of the MemoryContexts, it seemed to get
awkward quickly. I'm open to suggestion if you can point me in the right
direction. Maybe I can peek at the sizes of chunks holding state values
and group keys, and combine that with the hash table size-estimating
code?

> Moreover, this is about fourth or fifth down the
> list of the implementation problems with spilling hash aggregation to
> disk. It would be good to see credible solutions for the bigger issues
> before we buy into adding overhead for a mechanism with no uses in core.

I had several iterations of a full implementation of the spill-to-disk
HashAgg patch[1]. Tomas Vondra has some constructive review comments,
but all of them seemed solvable. What do you see as a major unsolved
issue?

If I recall, you were concerned about things like array_agg, where an
individual state could get larger than work_mem. That's a valid concern,
but it's not the problem I was trying to solve.

Regards,
Jeff Davis

[1]
http://www.postgresql.org/message-id/1407706010.6623.16.camel@jeff-desktop

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2015-06-15 03:13:51 Re: creating extension including dependencies
Previous Message David Rowley 2015-06-15 00:56:18 Re: Patch to improve a few appendStringInfo* calls