Re: Should we cacheline align PGXACT?

From: Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Should we cacheline align PGXACT?
Date: 2017-01-30 10:15:47
Message-ID: CAPpHfdtLAb3m9g+Qw6urtbehHFZjMETBt6hCwV+0PG907gXs6w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers

On Sat, Aug 20, 2016 at 9:38 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > Wow, nice results. My intuition on why PGXACT helped in the first place
> was that it minimized the number of cache lines that had to be touched to
> take a snapshot. Padding obviously would somewhat increase that again, so I
> can't quite understand why it seems to be helping... any idea?
>
> That's an interesting point. I wonder whether this whole thing will be
> useless or even counterproductive after (if) Heikki's CSN-snapshot patch
> gets in. I would certainly not mind reverting the PGXACT/PGPROC
> separation if it proves no longer helpful after that.
>

Assuming, we wouldn't realistically have CSN-snapshot patch committed to
10, I think we should consider PGXACT cache line alignment patch for 10.
Revision on PGXACT align patch is attached. Now it doesn't introduce new
data structure for alignment, but uses manually calculated padding. I
added static assertion that PGXACT is exactly PG_CACHE_LINE_SIZE because it
still have plenty of room for new fields before PG_CACHE_LINE_SIZE would be
exceeded.
Readonly pgbench results on 72 physically cores Intel server are attached.
It quite similar to results I posted before, but it's curious that
performance degradation of master on high concurrency became larger.

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

Attachment Content-Type Size
pgxact-align-2.patch application/octet-stream 2.4 KB
image/png 37.3 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2017-01-30 10:32:22 Re: Supporting huge pages on Windows
Previous Message Christoph Berg 2017-01-30 10:14:25 Re: One-shot expanded output in psql using \G