Re: Removing PD_ALL_VISIBLE - Mailing list pgsql-hackers

From Merlin Moncure
Subject Re: Removing PD_ALL_VISIBLE
Date
Msg-id CAHyXU0wze9TaX=1WvBuT3jmoy4kofBm=LHv1sXFzkeFCP-sENw@mail.gmail.com
Whole thread Raw
In response to Re: Removing PD_ALL_VISIBLE  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Removing PD_ALL_VISIBLE  (Jeff Davis <pgsql@j-davis.com>)
List pgsql-hackers
On Mon, Nov 26, 2012 at 3:03 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Mon, Nov 26, 2012 at 3:29 PM, Jeff Davis <pgsql@j-davis.com> wrote:
>> Your intuition here is better than mine, but I am still missing
>> something here. If we keep the buffer pinned, then there will be very
>> few pin/unpin cycles here, so  I don't see where the contention would
>> come from (any more than there is contention pinning the root of an
>> index).
>
> Based on previous measurements, I think there *is* contention pinning
> the root of an index.  Currently, I believe it's largely overwhelmed
> by contention from other sources, such as the buffer manager lwlocks
> and the very-evil ProcArrayLock.  However, I believe that as we fix
> those problems, this will start to percolate up towards the top of the
> heap.

Yup -- it (buffer pin contention on high traffic buffers) been caught
in the wild -- just maintaining the pin count was enough to do it in
at least one documented case.  Pathological workloads demonstrate
contention today and there's no good reason to assume it's limited
index root nodes -- i'm strongly suspicious buffer spinlock issues are
behind some other malfeasance we've seen recently.

merlin



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Suggestion for --truncate-tables to pg_restore
Next
From: Alvaro Herrera
Date:
Subject: Re: Failing SSL connection due to weird interaction with openssl