Re: About displaying NestLoopParam - Mailing list pgsql-hackers

From Richard Guo
Subject Re: About displaying NestLoopParam
Date
Msg-id CAMbWs48S_L0As8iDVM=u55_4_fv=0wHJOA1g65SUEPo1zSZ=7w@mail.gmail.com
Whole thread Raw
In response to About displaying NestLoopParam  (Richard Guo <guofenglinux@gmail.com>)
Responses Re: About displaying NestLoopParam
List pgsql-hackers

On Fri, Sep 16, 2022 at 5:59 PM Richard Guo <guofenglinux@gmail.com> wrote:
I'm not saying this is a bug, but just curious why param 0 cannot be
displayed as the referenced expression. And I find the reason is that in
function find_param_referent(), we have the 'in_same_plan_level' flag
controlling that if we have emerged from a subplan, i.e. not the same
plan level any more, we would not look further for the matching
NestLoopParam. Param 0 suits this situation.

And there is a comment there also saying,

    /*
     * NestLoops transmit params to their inner child only; also, once
     * we've crawled up out of a subplan, this couldn't possibly be
     * the right match.
     */
 
After thinking of this for more time, I still don't see the reason why
we cannot display NestLoopParam after we've emerged from a subplan.

It seems these params are from parameterized subqueryscan and their
values are supplied by an upper nestloop. These params should have been
processed in process_subquery_nestloop_params() that we just add the
PlannerParamItem entries to root->curOuterParams, in the form of
NestLoopParam, using the same PARAM_EXEC slots.

So I propose the patch attached to remove the 'in_same_plan_level' flag
so that we can display NestLoopParam across subplan. Please correct me
if I'm wrong.

Thanks
Richard
Attachment

pgsql-hackers by date:

Previous
From: Melih Mutlu
Date:
Subject: Re: Summary function for pg_buffercache
Next
From: Himanshu Upadhyaya
Date:
Subject: Re: HOT chain validation in verify_heapam()