Re: [HACKERS] Should we cacheline align PGXACT? - Mailing list pgsql-hackers

From Alexander Korotkov
Subject Re: [HACKERS] Should we cacheline align PGXACT?
Date
Msg-id CAPpHfdtGcHcrYYOYicXVRF4F3cJLcW_4phbP3HzYJxJB1bttzw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Should we cacheline align PGXACT?  (Ashutosh Sharma <ashu.coek88@gmail.com>)
Responses Re: [HACKERS] Should we cacheline align PGXACT?  (David Steele <david@pgmasters.net>)
Re: Should we cacheline align PGXACT?  (Simon Riggs <simon@2ndquadrant.com>)
List pgsql-hackers
On Fri, Mar 10, 2017 at 4:01 PM, Ashutosh Sharma <ashu.coek88@gmail.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 COUNTTPS (HEAD)TPS (PATCH)% IMPROVEMENT
436333368351.381664052
870179724963.301557446
161693031757433.803831001
323288373410933.727074508
6436335239984710.04397939
7237201141343711.13569222
12844397957835530.26629638
18032142055237371.85396055
196276780558896101.927885
256234563568951142.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 COUNTTPS (HEAD)TPS (PATCH)% IMPROVEMENT
4268326900.2609019754
8532153320.2067280586
1610348103870.3768844221
3219446197541.58387329
6428178281980.0709773582
7228296286391.212185468
12828577286000.0804843056
18026665275253.225201575
19627628285113.19603301
25628467285290.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

pgsql-hackers by date:

Previous
From: Rahila Syed
Date:
Subject: Re: [HACKERS] Adding support for Default partition in partitioning
Next
From: Amit Khandekar
Date:
Subject: Re: [HACKERS] Parallel Append implementation