From: | Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com> |
---|---|
To: | Zhihong Yu <zyu(at)yugabyte(dot)com> |
Cc: | Alexander Pyhalov <a(dot)pyhalov(at)postgrespro(dot)ru>, "Andrey V(dot) Lepikhov" <a(dot)lepikhov(at)postgrespro(dot)ru>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Defer selection of asynchronous subplans until the executor initialization stage |
Date: | 2022-04-06 06:58:29 |
Message-ID: | CAPmGK17uV9BoLnAmh845zcFpMEOEEaoqoYd3noC2WEkqkvvKHg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Apr 4, 2022 at 1:06 PM Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com> wrote:
> On Sun, Apr 3, 2022 at 11:38 PM Zhihong Yu <zyu(at)yugabyte(dot)com> wrote:
> > + WRITE_ENUM_FIELD(status, SubqueryScanStatus);
> >
> > Looks like the new field can be named subquerystatus - this way its purpose is clearer.
>
> I agree that “status” is too general. “subquerystatus” might be good,
> but I’d like to propose “scanstatus” instead, because I think this
> would be consistent with the naming of the RowMarkType-enum member
> “markType” in PlanRowMark defined in the same file.
>
> > + * mark_async_capable_plan
> > + * 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.
>
> Ok, how about something like this?
>
> “Check whether a given Path node is async-capable, and if so, mark the
> Plan node created from it as such and return true; otherwise, return
> false.”
I have committed the patch after modifying it as such. (I think we
can improve these later, if necessary.)
Best regards,
Etsuro Fujita
From | Date | Subject | |
---|---|---|---|
Next Message | vignesh C | 2022-04-06 06:59:18 | Re: Printing backtrace of postgres processes |
Previous Message | Kyotaro Horiguchi | 2022-04-06 06:53:32 | Re: API stability |