Robert Haas <> writes:
> On Wed, Apr 13, 2016 at 9:52 AM, Tom Lane <> wrote:
>> Robert Haas <> writes:
>>> I have never understood why you didn't include 64-bit atomics in the
>>> original atomics implementation, and I really think we should have
>>> committed a patch to add them long before now.

>> What will you do on 32-bit platforms (or, more generally, anything
>> lacking 64-bit-wide atomics)?

> We fall back to emulating it using spinlocks.

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.

> This isn't really an
> issue in practice because 32-bit x86 has native 64-bit atomics, and
> it's hard to point to another 32-bit platform that is likely to be
> have enough concurrency for the lack of 64-bit atomics to matter.

It's not concurrency I'm worried about, it's the sheer overhead of
going through the spinlock code.

I'd be okay with atomics that were defined as "pointer width", if
we have a need for that, but I'm suspicious of 64-bits-exactly.

                        regards, tom lane

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to