Re: Skylake-S warning
От | Andres Freund |
---|---|
Тема | Re: Skylake-S warning |
Дата | |
Msg-id | 20181004003052.er4qzbxccaddflmn@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Skylake-S warning (Daniel Wood <hexexpert@comcast.net>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: