On Sat, Aug 20, 2016 at 9:38 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Robert Haas <robertmh...@gmail.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
pgxact-align-2.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
