Re: Move PinBuffer and UnpinBuffer to atomics

From: Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, 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-14 20:29:36
Message-ID: CAPpHfdsKRvFhJW354PeVnAtMVS5wE-Yp4_82bhCtVepeNoia=g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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. However,
on low number of clients there is small regression. I think this
regression could be caused by alignment of other data structures.

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

Attachment Content-Type Size
image/png 30.9 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2016-04-14 21:46:18 Re: Broken API specification for walrcv_receive
Previous Message Stephen Frost 2016-04-14 20:29:32 Re: Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls