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,
Je
On 16 July 2015 at 05:07, 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.
>
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 dr
Hi,
On 07/15/2015 09:21 PM, Robert Haas wrote:
On Tue, Jul 14, 2015 at 9:14 PM, Tomas Vondra
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 (
On Wed, Jul 15, 2015 at 3:27 AM, Jeff Davis 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 fo
On Tue, Jul 14, 2015 at 9:14 PM, Tomas Vondra
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 unable to
> reproduce that on
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 HashA
On Wed, Jul 15, 2015 at 12:57 PM, Jeff Davis 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 ty
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 pal
Hi,
On 07/14/2015 10:19 PM, Robert Haas wrote:
On Sat, Jul 11, 2015 at 2:28 AM, Jeff Davis 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
On Sat, Jul 11, 2015 at 2:28 AM, Jeff Davis 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 lot bigger when
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.
On 7 July 2015 at 20:23, David Rowley wrote:
> On 7 July 2015 at 18:59, Jeff Davis 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 need to be updated during each al
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 meanin
On 7 July 2015 at 18:59, Jeff Davis 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 MEMORY_CONTEXT_CHECKING
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 y
On 15 June 2015 at 07: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().
>
> It also adds a new function, MemoryContextMemAllocated() which
On 15 June 2015 at 07:43, Jeff Davis wrote:
>
> * There was a slowdown reported of around 1-3% (depending on the exact
> version of the patch) on an IBM power machine when doing an index
> rebuild. The results were fairly noisy for me, but it seemed to hold up.
> See http://www.postgresql.org/mes
On Thu, Jul 2, 2015 at 11:37 AM, CK Tan 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 answered here:
htt
On 14 June 2015 at 23:51, Tomas Vondra 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 with a penalty.
>>
On 14 June 2015 at 23:51, Tomas Vondra 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 with a penalty.
>>
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
directi
Hi,
On 06/14/15 22:21, Tom Lane wrote:
Jeff Davis 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 th
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
appr
Jeff Davis 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
> reason to bloc
25 matches
Mail list logo
