Re: heads up: Fix for intel hardware bug will lead to performance regressions

On Mon, Jan 8, 2018 at 2:38 PM, Thomas Munro
<thomas(dot)munro(at)enterprisedb(dot)com> wrote:
> On Fri, Jan 5, 2018 at 6:28 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Tue, Jan 2, 2018 at 5:23 PM, Andres Freund <andres(at)anarazel(dot)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.

Also pgarch.c, syncrep.c, walsender.c and walreceiver.c use
PostmasterIsAlive() every time through their loops[1] generating extra
syscalls, one instance of which has caused complaints before[1] on a
system where the syscall was expensive (arguably because that kernel
needs some work but still, it's an example of the thing you asked
about).

[1] https://www.postgresql.org/message-id/flat/20160915135755.GC19008%40genua.de

--
Thomas Munro
http://www.enterprisedb.com