From: | Richard Guo <guofenglinux(at)gmail(dot)com> |
---|---|
To: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: About displaying NestLoopParam |
Date: | 2022-09-20 08:55:11 |
Message-ID: | CAMbWs48S_L0As8iDVM=u55_4_fv=0wHJOA1g65SUEPo1zSZ=7w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Sep 16, 2022 at 5:59 PM Richard Guo <guofenglinux(at)gmail(dot)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 | Content-Type | Size |
---|---|---|
v1-0001-Display-NestLoopParam-across-subplan.patch | application/octet-stream | 4.6 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Himanshu Upadhyaya | 2022-09-20 08:59:52 | Re: HOT chain validation in verify_heapam() |
Previous Message | Melih Mutlu | 2022-09-20 08:47:40 | Re: Summary function for pg_buffercache |