Re: Hybrid Hash/Nested Loop joins and caching results from subplans - Mailing list pgsql-hackers

From Andy Fan
Subject Re: Hybrid Hash/Nested Loop joins and caching results from subplans
Date
Msg-id CAKU4AWqHDGetbRP-8DVFDhD0fPM52whpNW4wcZPCwe=QGBuGpQ@mail.gmail.com
Whole thread Raw
In response to Re: Hybrid Hash/Nested Loop joins and caching results from subplans  (David Rowley <dgrowleyml@gmail.com>)
Responses Re: Hybrid Hash/Nested Loop joins and caching results from subplans  (David Rowley <dgrowleyml@gmail.com>)
List pgsql-hackers


On Tue, Nov 10, 2020 at 7:55 AM David Rowley <dgrowleyml@gmail.com> wrote:
On Tue, 10 Nov 2020 at 12:49, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Alvaro Herrera <alvherre@alvh.no-ip.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.

I do happen to prefer having the separate Result Cache node (v8), so
from my point of view, even if the performance was equal, I'd rather
have v8. I understand that some others feel different though.


While I have interest about what caused the tiny difference,  I admit that what direction
this patch should go is more important.  Not sure if anyone is convinced that
v8 and v9 have a similar performance.  The current data show it is similar. I want to 
profile/read code more, but I don't know what part I should pay attention to.  So I think
any hints on why v9 should be better at a noticeable level  in theory should be very 
helpful.  After that, I'd like to read the code or profile more carefully. 

--
Best Regards
Andy Fan

pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: remove spurious CREATE INDEX CONCURRENTLY wait
Next
From: Michael Paquier
Date:
Subject: Re: remove spurious CREATE INDEX CONCURRENTLY wait