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-vTyXON6XjumbFPMw6RFRwXFsnATnzUpAvtafFRKzC=AQA@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 Sun, Apr 3, 2022 at 3:28 AM Etsuro Fujita <etsuro.fujita@gmail.com> wrote:
On Sun, Mar 13, 2022 at 6:39 PM Etsuro Fujita <etsuro.fujita@gmail.com> wrote:
> On Wed, Sep 15, 2021 at 3:40 PM Alexander Pyhalov
> <a.pyhalov@postgrespro.ru> wrote:
> > The patch looks good to me and seems to work as expected.
>
> I’m planning to commit the patch.
I polished the patch a bit:
* Reordered a bit of code in create_append_plan() in logical order (no
functional changes).
* Added more comments.
* Added/Tweaked regression test cases.
Also, I added the commit message. Attached is a new version of the
patch. Barring objections, I’ll commit this.
Best regards,
Etsuro Fujita
Hi,
+ WRITE_ENUM_FIELD(status, SubqueryScanStatus);
Looks like the new field can be named subquerystatus - this way its purpose is clearer.
+ * Check whether a given Path node is async-capable, and if so, mark the
+ * Plan node created from it as such.
Please add comment explaining what the return value means.
+ mark_async_capable_plan(plan,
+ ((ProjectionPath *) path)->subpath))
+ return true;
by returning true, `plan->async_capable = true;` is skipped.
Is that intentional ?
Cheers
В списке pgsql-hackers по дате отправления: