On Wed, Feb 15, 2017 at 12:14 PM, Tom Lane <[email protected]> wrote: > Robert Haas <[email protected]> writes: >> On Mon, Feb 13, 2017 at 11:07 AM, Alvaro Herrera >> <[email protected]> wrote: >>> It seems to me that Andres comments here were largely ignored: >>> https://www.postgresql.org/message-id/[email protected] >>> 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 protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
