Re: Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <
От | Tom Lane |
---|---|
Тема | Re: Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold < |
Дата | |
Msg-id | 22526.1460558523@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold < (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Re: [COMMITTERS] pgsql: Avoid extra locks in
GetSnapshotData if old_snapshot_threshold <
Re: Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold < |
Список | pgsql-hackers |
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. regards, tom lane
В списке pgsql-hackers по дате отправления: