Re: Memory Accounting - Mailing list pgsql-hackers

From Tomas Vondra
Subject Re: Memory Accounting
Date
Msg-id 20190926192244.mk5ru6nkofo7am3h@development
Whole thread Raw
In response to Re: Memory Accounting  (Melanie Plageman <melanieplageman@gmail.com>)
Responses Re: Memory Accounting
List pgsql-hackers
On Tue, Sep 24, 2019 at 11:46:49AM -0700, Melanie Plageman wrote:
>On Thu, Sep 19, 2019 at 11:00 AM Jeff Davis <pgsql@j-davis.com> wrote:
>
>> On Wed, 2019-09-18 at 13:50 -0700, Soumyadeep Chakraborty wrote:
>> > Hi Jeff,
>>
>> Hi Soumyadeep and Melanie,
>>
>> Thank you for the review!
>>
>> > max_stack_depth       max level       lazy (ms)       eager (ms)
>> (eage
>> > r/lazy)
>> > 2MB   82      302.715 427.554 1.4123978
>> > 3MB   3474    567.829 896.143 1.578191674
>> > 7.67MB        8694    2657.972        4903.063        1.844663149
>>
>> Thank you for collecting data on this. Were you able to find any
>> regression when compared to no memory accounting at all?
>>
>>
>We didn't spend much time comparing performance with and without
>memory accounting, as it seems like this was discussed extensively in
>the previous thread.
>
>
>> It looks like you agree with the approach and the results. Did you find
>> any other issues with the patch?
>>
>
>We didn't observe any other problems with the patch and agree with the
>approach. It is a good start.
>
>
>>
>> I am also including Robert in this thread. He had some concerns the
>> last time around due to a small regression on POWER.
>>
>
>I think it would be helpful if we could repeat the performance tests
>Robert did on that machine with the current patch (unless this version
>of the patch is exactly the same as the ones he tested previously).
>

I agree that would be nice, but I don't have access to any Power machine
suitable for this kind of benchmarking :-( Robert, any chance you still
have access to that machine?

It's worth mentioning that those bechmarks (I'm assuming we're talking
about the numbers Rober shared in [1]) were done on patches that used
the eager accounting approach (i.e. walking all parent contexts and
updating the accounting for them).

I'm pretty sure the current "lazy accounting" patches don't have that
issue, so unless someone objects and/or can show numbers demonstrating
I'wrong I'll stick to my plan to get this committed soon.

regards

[1]
https://www.postgresql.org/message-id/flat/CA%2BTgmobnu7XEn1gRdXnFo37P79bF%3DqLt46%3D37ajP3Cro9dBRaA%40mail.gmail.com#3e2dc9e70a9f9eb2d695ab94a580c5a2

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



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Shared Memory: How to use SYSV rather than MMAP ?
Next
From: Alvaro Herrera
Date:
Subject: Re: PATCH: logical_work_mem and logical streaming of largein-progress transactions