Re: Changing WAL Header to reduce contention during ReserveXLogInsertLocation()

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Robert Haas <robertmhaas(at)gmail(dot)com>, Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>, Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Changing WAL Header to reduce contention during ReserveXLogInsertLocation()
Date: 2018-04-03 16:20:05
Message-ID: 20180403162005.c6sajrm6bu6rfe6q@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2018-04-03 09:56:24 -0400, Tom Lane wrote:
> Heikki Linnakangas <hlinnaka(at)iki(dot)fi> writes:
> > But let's go back to why we're considering this. The idea was to
> > optimize this block:
> > ...
> > One trick that we could do is to replace that with a 128-bit atomic
> > compare-and-swap instruction. Modern 64-bit Intel systems have that,
> > it's called CMPXCHG16B. Don't know about other architectures. An atomic
> > fetch-and-add, as envisioned in the comment above, would presumably be
> > better, but I suspect that a compare-and-swap would be good enough to
> > move the bottleneck elsewhere again.
>
> +1 for taking a look at that. A bit of experimentation shows that
> recent gcc and clang can generate that instruction using
> __sync_bool_compare_and_swap or __sync_val_compare_and_swap
> on an __int128 value.

The problem will presumably be that early opteron AMD64s lacked that
instruction. I'm not sure which distributions still target them (windows
dropped support a few years ago), but we should make sure that neither
the necessary dispatch code isn't going to add so much overhead it's
eating into our margin, nor that the generated code SIGILLs on such
platforms.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2018-04-03 16:38:42 Re: Optimize Arm64 crc32c implementation in Postgresql
Previous Message Kapil Sharma 2018-04-03 16:12:48 Re: Running Installcheck remotely