Re: Speedup twophase transactions

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Stas Kelvich <s(dot)kelvich(at)postgrespro(dot)ru>
Cc: Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Speedup twophase transactions
Date: 2016-01-12 05:14:04
Message-ID: CANP8+jJpOFNwavqtU+r89VPfdehAVYos0gJY=0M2eFwjjus-3g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers

On 11 January 2016 at 23:11, Stas Kelvich <s(dot)kelvich(at)postgrespro(dot)ru> wrote:

> >
>
> On 11 Jan 2016, at 21:43, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> >
> > Have you measured lwlocking as a problem?
> >
>
> Yes. GXACT locks that wasn’t even in perf top 10 on dual Xeon moves to the
> first places when running on 60 core system. But Jesper’s flame graph on 24
> core system shows different picture.

I think we can use a shmem hash table to identify the GID by name during
LockGxact and avoid duplicates during prepare. Hashing on the first 16
bytes of the GID should be sufficient in most cases; the worst case would
be the same as it is now, all depending on how people use the GID name
field. The hash value can be calculated outside of the lock. We can also
partition the lock without risk, just adds a little extra code.

We can also optimize final removal (sketch of how to do that attached).

--
Simon Riggs http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Attachment Content-Type Size
2pc_remove_prepXacts.v1.patch application/octet-stream 2.2 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2016-01-12 05:58:29 Re: PATCH: add pg_current_xlog_flush_location function
Previous Message Michael Paquier 2016-01-12 04:55:14 Re: Request - repeat value of \pset title during \watch interations