| From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
|---|---|
| To: | Andy Fan <zhihui(dot)fan1213(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, 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-12-06 23:50:11 |
| Message-ID: | CAApHDvq9voUu5ShxOvdeFBR8LyWZBy0+SPHSt0N5qLOVaZ2tYw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sun, 6 Dec 2020 at 03:52, Andy Fan <zhihui(dot)fan1213(at)gmail(dot)com> wrote:
>
> On Fri, Dec 4, 2020 at 10:41 PM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
>>
>> I also
>> noticed that the code I'd written to build the cache lookup expression
>> included a step to deform the outer tuple. This was unnecessary and
>> slowed down the expression evaluation.
>>
>
> I thought it would be something like my 3rd suggestion on [1], however after
> I read the code, it looked like no. Could you explain what changes it is?
> I probably missed something.
Basically, an extra argument in ExecBuildParamSetEqual() which allows
the TupleTableSlotOps for the left and right side to be set
individually. Previously I was passing a single TupleTableSlotOps of
TTSOpsMinimalTuple. The probeslot is a TTSOpsVirtual tuple, so
passing TTSOpsMinimalTuple causes the function to add a needless
EEOP_OUTER_FETCHSOME step to the expression.
David
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Masahiko Sawada | 2020-12-07 00:30:03 | Re: Proposed patch for key managment |
| Previous Message | David Rowley | 2020-12-06 23:46:12 | Re: Hybrid Hash/Nested Loop joins and caching results from subplans |