| From: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: heads up: Fix for intel hardware bug will lead to performance regressions |
| Date: | 2018-01-08 01:38:20 |
| Message-ID: | CAEepm=2=c8M95btHo4x=4J-vWpwy1NZOE_BnCu6E8vP51GdWQg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
--
Thomas Munro
http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas Munro | 2018-01-08 02:21:30 | Re: Condition variable live lock |
| Previous Message | Nikita Glukhov | 2018-01-08 00:22:08 | Re: to_timestamp TZH and TZM format specifiers |