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: 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-02-15 08:49:38
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers


On Mon, Feb 13, 2017 at 8:02 PM, Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com>

> I too have performed benchmarking of this patch on a large machine
> (with 128 CPU(s), 520GB RAM, intel x86-64 architecture) and would like
> to share my observations for the same (Please note that, as I had to
> reverify readings on few client counts, it did take some time for me
> to share these test-results.)

Great! Thank you very much for testing.

Case3: Data fits in shared buffer, Read-write workload:
> ------------------------------------------------------------
> -----------------
> In this case, I could see that the tps on head and patch are very
> close to each other with a small variation of (+-)3-4% which i assume
> is a run-to-run variation. PFA result sheet
> 'results-readwrite-300-1000-SF' containing the test-results.

I wouldn't say it's just a variation. It looks like relatively small but
noticeable regression in the patch.
According to Andres comment [1] I made a version of patch
(pgxact-align-3.patch) which align PGXACT to 16 bytes.
That excludes situation when single PGXACT is spread over 2 cache lines.
Results of read-only tests are attached. We can see that 16-byte alignment
gives speedup in read-only tests, but it's a bit less than speedup of cache
line alignment version.
Read-write tests are now running. Hopefully 16-byte alignment version of
patch wouldn't cause regression in read-write benchmark.


Alexander Korotkov
Postgres Professional:
The Russian Postgres Company

Attachment Content-Type Size
pgxact-align-3.patch application/octet-stream 2.6 KB
image/png 45.0 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2017-02-15 09:25:37 Re: Proposal: GetOldestXminExtend for ignoring arbitrary vacuum flags
Previous Message Simon Riggs 2017-02-15 08:32:49 Re: Proposal: GetOldestXminExtend for ignoring arbitrary vacuum flags