On Mon, Jan 8, 2018 at 2:38 PM, Thomas Munro
<thomas.munro@enterprisedb.com> wrote:
> 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.
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
