| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
| Cc: | 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 13:56:24 |
| Message-ID: | 2140.1522763784@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tomas Vondra | 2018-04-03 13:56:50 | Re: [HACKERS] logical decoding of two-phase transactions |
| Previous Message | Claudio Freire | 2018-04-03 13:37:38 | Re: [HACKERS] [PATCH] Vacuum: Update FSM more frequently |