Re: Skylake-S warning

From: Andres Freund <andres(at)anarazel(dot)de>
To: Daniel Wood <hexexpert(at)comcast(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Skylake-S warning
Date: 2018-10-04 00:30:52
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 2018-10-03 17:01:44 -0700, Daniel Wood wrote:
> > On October 3, 2018 at 3:55 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> > In the thread around
> > I'd found doing more aggressive padding helped a lot. Unfortunately I
> > didn't pursue this further :(
> Interesting. Looks like you saw the same thing I see now.
> > I really suspect we're going to have to change the layout of PGXACT data
> > in a way that makes a contiguous scan possible. That'll probably require
> > some uglyness because a naive "use first free slot" scheme obviously is
> > sensitive to there being holes. But I suspect that a scheme were
> > backends would occasionally try to move themselves to an earlier slot
> > wouldn't be too hard to implement.
> I've also thought of this. But someone could create a thousand connections and
> then disconnect all but the first and last creating a huge hole.

Yea, that's what I was suggesting to address with "a scheme where
backends would occasionally try to move to move themselves to an earlier
slot". I was basically thinking that in occasions where a backend holds
ProcArrayLock exclusively it could just compare the current number of
connections and its slot and move itself earlier if it's more than, say,
10% after the #num-connection's slot. Or something.

The advantage of that approach would be that the size of the change is
probably fairly manageable.


Andres Freund

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Iwata, Aya 2018-10-04 01:03:53 RE: Function for listing archive_status directory
Previous Message Daniel Wood 2018-10-04 00:28:59 Re: Skylake-S warning