Re: Proposal: New LWLockmode LW_OWNER

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Jignesh K(dot) Shah" <J(dot)K(dot)Shah(at)Sun(dot)COM>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Proposal: New LWLockmode LW_OWNER
Date: 2008-06-06 18:38:52
Message-ID: 1212777532.12046.28.camel@ebony.site
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On Fri, 2008-06-06 at 12:39 -0400, Tom Lane wrote:
> "Jignesh K. Shah" <J(dot)K(dot)Shah(at)Sun(dot)COM> writes:
> > New Lock Mode Proposed: LW_EX_OWNER (input on better name will be
> > appreciated).
>
> This seems rather crazy, and you haven't actually given a single
> convincing use-case. Shouldn't you be trying to break down a lock
> into multiple locks instead of inventing new lock semantics that
> nobody really understands?

I understand why Jignesh has approached it this way, having talked some
at PGCon about this.

Splitting ProcArray into multiple pieces is likely to slow down access
to the ProcArray for everyone, since shared accessors want the whole
thing, but we should try that also as you suggest.

Allowing a lock mode where the individual pieces are accessible as a
whole or individually does make some sense. This is a different
situation than buffer and lock table access, where there was no common
workload that needed access to all partitions.

So I think its a reasonable idea, with a complex sounding name. The main
issue is proving it helps the target workload, and doesn't hinder other
workloads. We should do that before we think of a better name. There are
other possibilities as well, but my feeling is that we should explore
them all - so lets give this idea enough space to show its worth, if
any.

Personally, I don't see it being applicable to WAL buffers though. That
is a different situation again and we have a couple of workable ideas on
the table already. That doesn't detract from this idea's possible worth.
Unique and important situations need unique solutions.

So, please can we see some perf results? Big gains justify extra code.

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andreas Pflug 2008-06-06 18:46:07 Re: Overhauling GUCS
Previous Message Andreas Pflug 2008-06-06 18:33:13 Re: Overhauling GUCS