From: | Richard Guo <guofenglinux(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Allowing parallel-safe initplans |
Date: | 2023-04-19 02:42:08 |
Message-ID: | CAMbWs48zKHjyFtzY4y0OR85EyV=C2bOioNRtJrjWaZ9BLAhB1g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Apr 18, 2023 at 9:33 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Richard Guo <guofenglinux(at)gmail(dot)com> writes:
> > It seems that in this case the top_plan does not have any extParam, so
> > the Gather node that is added atop the top_plan does not have a chance
> > to get its initParam filled in set_param_references().
>
> Oh, so maybe we'd need to copy up extParam as well? But it's largely
> moot, since I don't see a good way to avoid breaking the EXPLAIN
> output.
Yeah, seems breaking the EXPLAIN output is inevitable if we move the
initPlans to the Gather node. So maybe we need to keep the logic as in
v1 patch, i.e. avoid adding a Gather node when top_plan has initPlans.
If we do so, I wonder if we need to explain the potential wrong results
issue in the comments.
Thanks
Richard
From | Date | Subject | |
---|---|---|---|
Next Message | Junwang Zhao | 2023-04-19 03:26:26 | Use INT_MAX for wal size related gucs's max value |
Previous Message | Jonathan S. Katz | 2023-04-19 02:31:15 | Re: check_strxfrm_bug() |