Re: Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <

On Wed, Apr 13, 2016 at 10:42 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Wed, Apr 13, 2016 at 10:20 AM, Tom Lane <tgl@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.
>
> 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.

One of us is confused, or we're just talking past each other, because
I don't think I'm ignoring your point at all.  In fact, I think I just
responded to it rather directly.  I agree that the exact risk you are
describing exists.  However, the multiple spinlock cycles that you are
concerned about will only occur on a platform that doesn't support
64-bit atomics.  In order to test whether there is a performance
problem on such hardware, or how serious that problem is, we'd need to
have access to such hardware, and I don't know where to find any such
hardware.  Do you?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company