On Wed, Feb 15, 2017 at 12:14 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Mon, Feb 13, 2017 at 11:07 AM, Alvaro Herrera >> <alvhe...@2ndquadrant.com> wrote: >>> It seems to me that Andres comments here were largely ignored: >>> https://www.postgresql.org/message-id/20160822021747.u5bqx2xwwjzac...@alap3.anarazel.de >>> He was suggesting to increase the struct size to 16 bytes rather than >>> going all the way up to 128. Did anybody test this? > >> So, I think that going up to 128 bytes can't really make sense. If >> that's the best-performing solution here, then maybe what we ought to >> be doing is reverting the PGXACT/PGPROC separation, sticking these >> critical members at the beginning, and padding the whole PGXACT out to >> a multiple of the cache line size. > > Yes. That separation was never more than a horribly ugly kluge. > I would love to see it go away. But keeping it *and* padding > PGXACT to something >= the size of PGPROC borders on insanity.
I don't think it would be bigger than a PGPROC. PGPROCs are really big, 816 bytes on my MacBook Pro. But if you did what I suggested, you could take a snapshot by touching 1 cache line per backend. They wouldn't be consecutive; it would be an upward pattern, with skips. If you pad PGXACT out to one cache line, you could likewise take a snapshot by touching 1 cache line per backend, and they'd be consecutive. Maybe that difference matters to the memory prefetching controller, I dunno, but it seems funny that we did the PGXACT work to reduce the number of cache lines that had to be touched in order to take a snapshot to improve performance, and now we're talking about increasing it again, also to improve performance. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers