On 2018-10-03 17:01:44 -0700, Daniel Wood wrote:
>
> > On October 3, 2018 at 3:55 PM Andres Freund <andres@anarazel.de> wrote:
>
> > In the thread around https://www.postgresql.org/message-id/20160411214029.ce3fw6zxim5k6a2r@alap3.anarazel.de
> > 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.
Greetings,
Andres Freund
