Re: Defer selection of asynchronous subplans until the executor initialization stage
От | Zhihong Yu |
---|---|
Тема | Re: Defer selection of asynchronous subplans until the executor initialization stage |
Дата | |
Msg-id | CALNJ-vSw2_Hy7pwWS6JEKDtPOejSyjv_XrqtTKH4BhfLvJSPSg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Defer selection of asynchronous subplans until the executor initialization stage (Etsuro Fujita <etsuro.fujita@gmail.com>) |
Ответы |
Re: Defer selection of asynchronous subplans until the executor initialization stage
|
Список | pgsql-hackers |
On Thu, Jun 2, 2022 at 5:08 AM Etsuro Fujita <etsuro.fujita@gmail.com> wrote:
On Wed, Apr 6, 2022 at 3:58 PM Etsuro Fujita <etsuro.fujita@gmail.com> wrote:
> I have committed the patch after modifying it as such.
The patch calls trivial_subqueryscan() during create_append_plan() to
determine the triviality of a SubqueryScan that is a child of an
Append node. Unlike when calling it from
set_subqueryscan_references(), this is done before some
post-processing such as set_plan_references() on the subquery. The
reason why this is safe wouldn't be that obvious, so I added to
trivial_subqueryscan() comments explaining this. Attached is a patch
for that.
Best regards,
Etsuro Fujita
Hi,
Suggestion on formatting the comment:
+ * set_plan_references() modifies the tlist for every plan node in the
It would be more readable if `2)` is put at the beginning of the second line above.
+ * might delete the topmost plan node like an Append or MergeAppend from the
Similarly you can move `3) set_plan_references()` to the beginning of the next line.
Cheers
В списке pgsql-hackers по дате отправления: