Re: Reduce ProcArrayLock contention
| От | Amit Kapila |
|---|---|
| Тема | Re: Reduce ProcArrayLock contention |
| Дата | |
| Msg-id | CAA4eK1L=SARSZeB-HDHP194tjpEV0b3ELahnDzz8mrtHvb+LnA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Reduce ProcArrayLock contention (Amit Kapila <amit.kapila16@gmail.com>) |
| Ответы |
Re: Reduce ProcArrayLock contention
|
| Список | pgsql-hackers |
On Fri, Jul 31, 2015 at 10:11 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Wed, Jul 29, 2015 at 11:48 PM, Andres Freund <andres@anarazel.de> wrote:
> >
> > On 2015-07-29 12:54:59 -0400, Robert Haas wrote:
> > > I would try to avoid changing lwlock.c. It's pretty easy when so
> > > doing to create mechanisms that work now but make further upgrades to
> > > the general lwlock mechanism difficult. I'd like to avoid that.
> >
> > I'm massively doubtful that re-implementing parts of lwlock.c is the
> > better outcome. Then you have two different infrastructures you need to
> > improve over time.
>
> I agree and modified the patch to use 32-bit atomics based on idea
> suggested by Robert and didn't modify lwlock.c.
While looking at patch, I found that the way it was initialising the list
>
> On Wed, Jul 29, 2015 at 11:48 PM, Andres Freund <andres@anarazel.de> wrote:
> >
> > On 2015-07-29 12:54:59 -0400, Robert Haas wrote:
> > > I would try to avoid changing lwlock.c. It's pretty easy when so
> > > doing to create mechanisms that work now but make further upgrades to
> > > the general lwlock mechanism difficult. I'd like to avoid that.
> >
> > I'm massively doubtful that re-implementing parts of lwlock.c is the
> > better outcome. Then you have two different infrastructures you need to
> > improve over time.
>
> I agree and modified the patch to use 32-bit atomics based on idea
> suggested by Robert and didn't modify lwlock.c.
While looking at patch, I found that the way it was initialising the list
to be empty was wrong, it was using pgprocno as 0 to initialise the
list, as 0 is a valid pgprocno. I think we should use a number greater
that PROCARRAY_MAXPROC (maximum number of procs in proc
array).
Apart from above fix, I have modified src/backend/access/transam/README
to include the information about the improvement this patch brings to
reduce ProcArrayLock contention.
Вложения
В списке pgsql-hackers по дате отправления: