Re: Move PinBuffer and UnpinBuffer to atomics

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Merlin Moncure <mmoncure(at)gmail(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, YUriy Zhuravlev <u(dot)zhuravlev(at)postgrespro(dot)ru>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Move PinBuffer and UnpinBuffer to atomics
Date: 2016-04-17 16:35:59
Message-ID: CAA4eK1KXio7Akm+=cLsa_GUT04bHQa3OxH1_hELrTA8V7kaG8A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Apr 15, 2016 at 1:59 AM, Alexander Korotkov <
a(dot)korotkov(at)postgrespro(dot)ru> wrote:

> On Thu, Apr 14, 2016 at 5:35 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
>
>> On 2016-04-14 07:59:07 +0530, Amit Kapila wrote:
>> > What you want to see by prewarming?
>>
>> Prewarming appears to greatly reduce the per-run variance on that
>> machine, making it a lot easier to get meaningful results. Thus it'd
>> make it easier to compare pre/post padding numbers.
>>
>> > Will it have safe effect, if the tests are run for 10 or 15 mins
>> > rather than 5 mins?
>>
>> s/safe/same/? If so, no, I doesn't look that way. The order of buffers
>> appears to play a large role; and it won't change in a memory resident
>> workload over one run.
>>
>
> I've tried to run read-only benchmark of pad_pgxact_v1.patch on 4x18 Intel
> machine. The results are following.
>
> clients no-pad pad
> 1 12997 13381
> 2 26728 25645
> 4 52539 51738
> 8 103785 102337
> 10 132606 126174
> 20 255844 252143
> 30 371359 357629
> 40 450429 443053
> 50 497705 488250
> 60 564385 564877
> 70 718860 725149
> 80 934170 931218
> 90 1152961 1146498
> 100 1240055 1300369
> 110 1207727 1375706
> 120 1167681 1417032
> 130 1120891 1448408
> 140 1085904 1449027
> 150 1022160 1437545
> 160 976487 1441720
> 170 978120 1435848
> 180 953843 1414925
>
> snapshot_too_old patch was reverted in the both cases.
> On high number of clients padding gives very significant benefit.
>

These results indicates that the patch is a win. Are these results median
of 3 runs or single run data. By the way can you share the output of lscpu
command on this m/c.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2016-04-17 17:04:37 Re: [HACKERS] Re: pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <
Previous Message Amit Kapila 2016-04-17 16:32:23 Re: Move PinBuffer and UnpinBuffer to atomics