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  (Etsuro Fujita <etsuro.fujita@gmail.com>)
Список 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:

+ * node (or that for any plan node in the subplan tree), 2)
+ * 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.

+ * preserves the length and order of the tlist, and 3) set_plan_references()
+ * 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 по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: [RFC] building postgres with meson
Следующее
От: Tom Lane
Дата:
Сообщение: Re: compiler warnings with gcc 4.8 and -Og