Re: heads up: Fix for intel hardware bug will lead to performance regressions
От | Thomas Munro |
---|---|
Тема | Re: heads up: Fix for intel hardware bug will lead to performance regressions |
Дата | |
Msg-id | CAEepm=2=c8M95btHo4x=4J-vWpwy1NZOE_BnCu6E8vP51GdWQg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: heads up: Fix for intel hardware bug will lead to performance regressions (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: heads up: Fix for intel hardware bug will lead to performance regressions
Re: heads up: Fix for intel hardware bug will lead to performanceregressions |
Список | pgsql-hackers |
On Fri, Jan 5, 2018 at 6:28 AM, Robert Haas <robertmhaas@gmail.com> wrote: > On Tue, Jan 2, 2018 at 5:23 PM, Andres Freund <andres@anarazel.de> wrote: >> Note that real-world scenarios probably will see somewhat smaller >> impact, as this was measured over a loopback unix sockets which'll have >> smaller overhead itself than proper TCP sockets + actual network. > > What about scenarios with longer-running queries? > > Is it feasible to think about reducing the number of system calls we > issue in cases that weren't previously worth optimizing? Maybe the places where syscall rate is controlled by arbitrary buffer sizes? Examples: 8kB BufFile buffers and 128kB replication stream buffers. Just an idea, not sure if it's worth looking into; maybe we already spend enough time filling those buffers that a 50% syscall markup won't hurt. -- Thomas Munro http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: