From: | Daniel Wood <hexexpert(at)comcast(dot)net> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Skylake-S warning |
Date: | 2018-10-04 00:28:59 |
Message-ID: | 421124293.166525.1538612939250@connect.xfinity.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
One other thought. Could we update pgxact->xmin less often? What would be the impact of this lower bound being lower than it would normally be with the existing scheme. Yes, it needs to be moved forward "occasionally".
FYI, be careful with padding PGXACT's to a full cache line. With 1024 clients you'd completely blow out the L1 cache. The benefits with less than 200 clients is dubious. One problem with multiple(5) pgxact's in a single cache line is that you may get a miss fetching xmin and then a second miss fetching xid because an invalidation occurs between the 2 fetches from updating any of the other 5 pgxact's on the same cache line. I've found some improvement fetching both xmin and xid with a single 64 bit fetch. This prevents the invalidation between the two fetches. Similarily updating them with a single 64 bit write helps.
Yes, this is uber tweaky.
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2018-10-04 00:30:52 | Re: Skylake-S warning |
Previous Message | Michael Paquier | 2018-10-04 00:27:55 | Re: partition tree inspection functions |