Re: Proposal: New LWLockmode LW_OWNER - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Proposal: New LWLockmode LW_OWNER
Date
Msg-id 1212777532.12046.28.camel@ebony.site
Whole thread Raw
In response to Re: Proposal: New LWLockmode LW_OWNER  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, 2008-06-06 at 12:39 -0400, Tom Lane wrote:
> "Jignesh K. Shah" <J.K.Shah@Sun.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.comPostgreSQL Training, Services and Support



pgsql-hackers by date:

Previous
From: Andreas Pflug
Date:
Subject: Re: Overhauling GUCS
Next
From: Andreas Pflug
Date:
Subject: Re: Overhauling GUCS