On 2016-04-13 10:42:03 -0400, Tom Lane wrote: > Robert Haas <robertmh...@gmail.com> writes: > > On Wed, Apr 13, 2016 at 10:20 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > >> That's what I thought you were going to say, and it means that any > >> "performance improvement" patch that relies on 64-bit atomics in hotspot > >> code paths is going to be a complete disaster on anything but modern Intel > >> hardware. I'm not sure that's a direction we want to go in. We need to > >> stick to a set of atomics that's pretty widely portable. > > > I think 64-bit atomics *are* pretty widely portable. Can you name a > > system with more than 4 CPU cores that doesn't support them? > > No, you're ignoring my point, which is what happens on single-CPU > 32-bit machines, and whether we aren't going to destroy performance > on low-end machines in pursuit of better performance on high-end.
I think generally the only platform of concern wrt is arm (< armv8), which doesn't have 64bit atomicity and doesn't have single-copy-atomicity for 8 byte values either (C.f. https://wiki.postgresql.org/wiki/Atomics). But: > Now, to the extent that a patch uses a 64-bit atomic op to replace > a spinlock acquisition, it might be pretty much a wash if low-end > machines have to use a spinlock to emulate the atomic op. But it > would be really easy for the translation to replace one spinlock > acquisition with multiple spinlock acquisitions, and that would hurt. Which is why I'm actually proposing to *not* use a pg_atomic_uint64, just a single define to remove the spinlock acquisition: http://archives.postgresql.org/message-id/20160413150839.mevdlgekizxyjhc5%40alap3.anarazel.de I think there are a number of LSNs which we'd be better of replacing LSN manipulations with an actual atomic operation (including fallback to the spinlock) might be beneficial. But that'd be a larger patch, and would require more testing; which is why I'm proposing the above. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
