Re: heads up: Fix for intel hardware bug will lead to performance regressions - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: heads up: Fix for intel hardware bug will lead to performance regressions
Date
Msg-id CAEepm=2=c8M95btHo4x=4J-vWpwy1NZOE_BnCu6E8vP51GdWQg@mail.gmail.com
Whole thread Raw
In response to Re: heads up: Fix for intel hardware bug will lead to performance regressions  (Robert Haas <robertmhaas@gmail.com>)
Responses 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
List 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 by date:

Previous
From: Nikita Glukhov
Date:
Subject: Re: to_timestamp TZH and TZM format specifiers
Next
From: Thomas Munro
Date:
Subject: Re: Condition variable live lock