From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, David Rowley <dgrowleyml(at)gmail(dot)com>, Andy Fan <zhihui(dot)fan1213(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Hybrid Hash/Nested Loop joins and caching results from subplans |
Date: | 2020-11-09 23:55:38 |
Message-ID: | CAH2-Wznx5XcHLMmjA8me7MrGGBx52va5==D6hcmScoNNFVVr+w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Nov 9, 2020 at 3:49 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
> > Are you taking into account the possibility that generated machine code
> > is a small percent slower out of mere bad luck? I remember someone
> > suggesting that they can make code 2% faster or so by inserting random
> > no-op instructions in the binary, or something like that. So if the
> > difference between v8 and v9 is that small, then it might be due to this
> > kind of effect.
>
> Yeah. I believe what this arises from is good or bad luck about relevant
> tight loops falling within or across cache lines, and that sort of thing.
> We've definitely seen performance changes up to a couple percent with
> no apparent change to the relevant code.
That was Andrew Gierth. And it was 5% IIRC.
In theory it should be possible to control for this using a tool like
stabilizer:
https://github.com/ccurtsinger/stabilizer
I am not aware of anybody having actually used the tool with Postgres,
though. It looks rather inconvenient.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2020-11-10 00:13:22 | Re: MultiXact\SLRU buffers configuration |
Previous Message | David Rowley | 2020-11-09 23:55:01 | Re: Hybrid Hash/Nested Loop joins and caching results from subplans |