On Mon, Jan 8, 2018 at 2:38 PM, Thomas Munro <thomas.mu...@enterprisedb.com> wrote: > On Fri, Jan 5, 2018 at 6:28 AM, Robert Haas <robertmh...@gmail.com> wrote: >> On Tue, Jan 2, 2018 at 5:23 PM, Andres Freund <and...@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
