On Fri, 2015-07-17 at 15:52 +1200, David Rowley wrote:
Should we mark the patch as returned with feedback in the commitfest
app then?
I believe the memory accounting patch has been rejected. Instead, the
work will be done in the HashAgg patch.
Thank you for the review!
Regards,
Jeff
On 16 July 2015 at 05:07, Jeff Davis pg...@j-davis.com wrote:
On Wed, 2015-07-15 at 12:59 +0530, Atri Sharma wrote:
I think a heuristic would be more suited here and ignoring memory
consumption for internal types means that we are not making the memory
accounting useful for a set of
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
On Wed, Jul 15, 2015 at 12:57 PM, 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
On Wed, 2015-07-15 at 12:59 +0530, Atri Sharma wrote:
I think a heuristic would be more suited here and ignoring memory
consumption for internal types means that we are not making the memory
accounting useful for a set of usecases.
OK, I will drop this patch and proceed with the HashAgg
On Tue, Jul 14, 2015 at 9:14 PM, Tomas Vondra
tomas.von...@2ndquadrant.com wrote:
Firstly, do we really have good benchmarks and measurements? I really doubt
that. We do have some numbers for REINDEX, where we observed 0.5-1%
regression on noisy results from a Power machine (and we've been
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
Hi,
On 07/15/2015 09:21 PM, Robert Haas wrote:
On Tue, Jul 14, 2015 at 9:14 PM, Tomas Vondra
tomas.von...@2ndquadrant.com wrote:
Firstly, do we really have good benchmarks and measurements? I really doubt
that. We do have some numbers for REINDEX, where we observed 0.5-1%
regression on noisy
Hi,
On 07/15/2015 07:07 PM, Jeff Davis wrote:
On Wed, 2015-07-15 at 12:59 +0530, Atri Sharma wrote:
I think a heuristic would be more suited here and ignoring memory
consumption for internal types means that we are not making the
memory accounting useful for a set of usecases.
OK, I will
On Sat, Jul 11, 2015 at 2:28 AM, Jeff Davis pg...@j-davis.com wrote:
After talking with a few people at PGCon, small noisy differences in CPU
timings can appear for almost any tweak to the code, and aren't
necessarily cause for major concern.
I agree with that in general, but the concern is a
Hi,
On 07/14/2015 10:19 PM, Robert Haas wrote:
On Sat, Jul 11, 2015 at 2:28 AM, Jeff Davis pg...@j-davis.com wrote:
After talking with a few people at PGCon, small noisy differences
in CPU timings can appear for almost any tweak to the code, and
aren't necessarily cause for major concern.
I
On Thu, 2015-07-09 at 14:41 +1200, David Rowley wrote:
Are you going to implement this? or are you happy with the single
level context tracking is the right thing?
I'm going to mark the patch as waiting on author for now.
Attached a version of the patch that does multi-level tracking, v12. It
On 7 July 2015 at 20:23, David Rowley david.row...@2ndquadrant.com wrote:
On 7 July 2015 at 18:59, Jeff Davis pg...@j-davis.com wrote:
One other thing that I don't remember seeing discussed would be to
just store a List in each context which would store all of the
mem_allocated's that
On Tue, 2015-07-07 at 16:49 +1200, David Rowley wrote:
of performance decrease anywhere. I'm just getting too much variation
in the test results to get any sort of idea.
That was my experience as well. Thank you for taking a look.
My main question here is: How sure are you that none of your
On 7 July 2015 at 18:59, Jeff Davis pg...@j-davis.com wrote:
On Tue, 2015-07-07 at 16:49 +1200, David Rowley wrote:
I might be mistaken here, but can't you just set context-mem_allocted
= 0; after that loop?
Or maybe it would be an improvement to only do the decrement
if
On 2015-07-07 16:49:58 +1200, David Rowley wrote:
I've been looking at this patch and trying to reproduce the reported
slowdown by using Tomas' function to try to exercise palloc() with minimal
overhead of other code:
https://github.com/tvondra/palloc_bench
That's not necessarily
On 15 June 2015 at 07:43, Jeff Davis pg...@j-davis.com wrote:
This patch tracks memory usage (at the block level) for all memory
contexts. Individual palloc()s aren't tracked; only the new blocks
allocated to the memory context with malloc().
It also adds a new function,
On 14 June 2015 at 23:51, Tomas Vondra tomas.von...@2ndquadrant.com wrote:
The current state, where HashAgg just blows up the memory, is just not
reasonable, and we need to track the memory to fix that problem.
Meh. HashAgg could track its memory usage without loading the entire
system
On 14 June 2015 at 23:51, Tomas Vondra tomas.von...@2ndquadrant.com wrote:
The current state, where HashAgg just blows up the memory, is just not
reasonable, and we need to track the memory to fix that problem.
Meh. HashAgg could track its memory usage without loading the entire
system
On Thu, Jul 2, 2015 at 11:37 AM, CK Tan ck...@vitessedata.com wrote:
I am sorry to ask questions unrelated to the subject, but how is tracking
memory going to fix the HashAgg blow up problem? Is there a plan to make
HashAgg not blow up (i.e. spill the hash table)?
Your question is probably
Jeff Davis pg...@j-davis.com writes:
This patch tracks memory usage (at the block level) for all memory
contexts. Individual palloc()s aren't tracked; only the new blocks
allocated to the memory context with malloc().
...
My general answer to the performance concerns is that they aren't a
Hi,
On 06/14/15 22:21, Tom Lane wrote:
Jeff Davis pg...@j-davis.com writes:
This patch tracks memory usage (at the block level) for all memory
contexts. Individual palloc()s aren't tracked; only the new blocks
allocated to the memory context with malloc().
...
My general answer to the
Hi,
On 06/14/15 21:43, Jeff Davis wrote:
This patch tracks memory usage (at the block level) for all memory
contexts. Individual palloc()s aren't tracked; only the new blocks
allocated to the memory context with malloc().
I see it's adding the new field as int64 - wouldn't a Size be more
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
24 matches
Mail list logo
