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

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

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?

>> 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'm not sure I understand exactly what the concern is here. I agree
that there is a possibility that any patch which uses 64-bit atomics
could regress performance on platforms that do not support 64-bit
atomics. That's why I argued initially against having fallbacks for
*any* atomic operations; I was of the opinion that we should be
prepared to carry two implementations of anything that was going to
depend on atomics. I lost that argument, perhaps for the best. I
think one of the problems here is that very few of us have any
hardware available which we could even use to test performance on
systems that lack support for both 32 and 64 bit atomics. We can
compile without atomics on the hardware we do have and see how that
goes, but that's not necessarily indicative of what will happen on
some altogether different CPU architecture. In some cases there might
be an emulator, like the VAX emulator Greg Stark was playing with, but
that's not necessarily indicative either, and also, really, who cares?

I think it would be cool if somebody started a project to try to
optimize the performance of PostgreSQL on, say, a Raspberry Pi. Then
we might learn whether any of this stuff actually matters there or
whether the problems are completely elsewhere (like too much
per-backend memory consumption). However, for reasons that are
probably sort of obvious, I doubt I'll have much luck getting
EnterpriseDB to fund work on that project - if it ever happens, it
will probably have to be the work of a dedicated hobbiest, or somebody
who has a tangible need to build an embedded system using PostgreSQL.

> 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.

I think LSNs are an important case, and they are not pointer width.

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