Re: Should we cacheline align PGXACT?

From: Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>
To: Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Bernd Helmle <mailings(at)oopsware(dot)de>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Should we cacheline align PGXACT?
Date: 2017-03-10 13:08:18
Message-ID: CAPpHfdtGcHcrYYOYicXVRF4F3cJLcW_4phbP3HzYJxJB1bttzw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Mar 10, 2017 at 4:01 PM, Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com>
wrote:

> > I agree. Probably Simon's patch for reducing pgxact access could negate
> > regression in pgxact alignment patch.
> > Ashutosh, could please you run read-write and read-only tests when both
> > these patches applied?
>
> I already had the results with both the patches applied. But, as I was not
> quite
> able to understand on how Simon's patch for reducing pgxact access could
> negate the regression on read-write workload that we saw with
> pgxact-align-3
> patch earlier, I was slightly hesitant to share the results. Anyways, here
> are
> the results with combined patches on readonly and readwrite workload:
>
> 1) Results for read-only workload:
> ========================
> pgbench -i -s 300 postgres
> pgbench -M prepared -c $thread -j $thread -T $time_for_reading -S postgres
>
> where, time_for_reading = 10mins
> *non default param:*
> shared_buffers=8GB
> max_connections=300
>
> CLIENT COUNT TPS (HEAD) TPS (PATCH) % IMPROVEMENT
> 4 36333 36835 1.381664052
> 8 70179 72496 3.301557446
> 16 169303 175743 3.803831001
> 32 328837 341093 3.727074508
> 64 363352 399847 10.04397939
> 72 372011 413437 11.13569222
> 128 443979 578355 30.26629638
> 180 321420 552373 71.85396055
> 196 276780 558896 101.927885
> 256 234563 568951 142.5578629
>
> 2) Results for read-write workload:
> =========================
> pgbench -i -s 300 postgres
> pgbench -M prepared -c $thread -j $thread -T $time_for_reading postgres
>
> where, time_for_reading = 30mins
>
> non default param:
> shared_buffers=8GB
> max_connections=300
>
>
> CLIENT COUNT TPS (HEAD) TPS (PATCH) % IMPROVEMENT
> 4 2683 2690 0.2609019754
> 8 5321 5332 0.2067280586
> 16 10348 10387 0.3768844221
> 32 19446 19754 1.58387329
> 64 28178 28198 0.0709773582
> 72 28296 28639 1.212185468
> 128 28577 28600 0.0804843056
> 180 26665 27525 3.225201575
> 196 27628 28511 3.19603301
> 256 28467 28529 0.2177960445
>

Results look good for me. Idea of committing both of patches looks
attractive.
We have pretty much acceleration for read-only case and small acceleration
for read-write case.
I'll run benchmark on 72-cores machine as well.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Khandekar 2017-03-10 13:12:17 Re: Parallel Append implementation
Previous Message Rahila Syed 2017-03-10 13:04:44 Re: Adding support for Default partition in partitioning