Re: "Value locking" Wiki page

On Wed, Oct 1, 2014 at 4:23 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> Quoting general research and other points about value locking are
> reasonable in the general section, but not in the description for 1.

I also made a similar comparison of #3. I don't think that reflects a bias.

> I'm glad you've called the first option "Heavyweight Page Locking".
> That name sums up what I see as the major objection to it, which is
> that performance and scalability of the whole server will be damaged
> signiciantly by using heavyweight locks for each row inserted. Please
> add that concern as a negative; I'm sure testing has been done, but
> not comparative testing against other techniques.

Comparative testing against both other techniques (#1, at a time when
#1 and #2 were otherwise comparable), and plain inserts and updates
has shown the performance to be very good. The evidence suggests that
using a heavyweight lock like this is fine. Don't promise tuples use
heavyweight locks? The coarser granularity did not appear to be
significant once we optimize retries to avoid hwlocking. #1 came out a
bit ahead of #2. So maybe the bloat of #2 is almost, but not quite,
cancelled out by the hwlocking coarseness. But then, I specifically
stated that it seemed that not having bloating was not much of an
advantage for #1.

We're going to have a benchmark between #1 and #2 when #2 is properly
integrated with the rest of the updated patch (just because we can).
#1 is the fastest of #1 and #2 last I checked, but there wasn't all
that much in it.

> I am motivated to
> explain the promise index tuple approach further because of this,
> which is an optimistic approach to locking.

> The stated disadvantages for 3 are not accurate, to put it mildly.

Honestly, how could I know what they are? The explanation I heard from
you and Andres has been very short on details. The points for #3 are
*my* concerns. I had to start somewhere. I'll consider your rebuttal
to those points that you make on a new thread separately.

> But that's been useful because what was a small thought experiment is
> beginning to look like a useful approach. I will post a summary of my
> understanding.

Thanks. Actually, this wiki page will probably pay for itself just by
allowing us to refer to #1, #2, and #3.

--
Peter Geoghegan