Re: Proposal: New LWLockmode LW_OWNER

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: Proposal: New LWLockmode LW_OWNER
Дата
Msg-id 1212777532.12046.28.camel@ebony.site
обсуждение исходный текст
Ответ на Re: Proposal: New LWLockmode LW_OWNER  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Andreas Pflug
Дата:
Сообщение: Re: Overhauling GUCS
Следующее
От: Andreas Pflug
Дата:
Сообщение: Re: Overhauling GUCS