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
